Interface member names that collide with protocol's own members are silently hidden
- Dominant language
- C++
- Stars
- 11
- Forks
- 4
- Avg merge
- 16h 39m
- Merged PRs (30d)
- 131
Description
`protocol` declares `swap`, `get_allocator` and `valueless_after_move` as members. The interface's functions are synthesised as members of a base class, so an interface that uses one of these names compiles but the library's function wins on `protocol`, while `protocol_view` still exposes the interface's function. There is no diagnostic.
```c++
struct I { int get_allocator() const; };
struct T { int get_allocator() const { return 42; } };
protocol p{T{}};
protocol_view v{p};
static_assert(!std::is_same_v); // library's member
static_assert( std::is_same_v); // interface's member
```
Confirmed on GCC trunk at f409dd2.
Options:
1. Reject such interfaces in `is_valid_interface` with a clear message.
2. Move the library's own operations out of the member namespace where the standard allows it (`swap` already has a hidden-friend form).
3. Document the reserved names in DRAFT.md.
1 and 3 together seem right; 2 is not available for `get_allocator` and `valueless_after_move`, which the standard spells as members on `polymorphic` and the containers.
This is also the reason #314 should not add a member named `type`.
Contributor guide
Research direction
Start by reading is_valid_interface and DRAFT.md, then inspect how protocol and protocol_view expose interface members. Compare the handling of swap, get_allocator, and valueless_after_move with the issue's example. Done means the chosen approach is settled, the collision is no longer silent, and the reserved-name behavior is documented or diagnosed clearly.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend-api-design
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100