Conversion functions on an interface are neither forwarded nor rejected
- Dominant language
- C++
- Stars
- 11
- Forks
- 4
- Avg merge
- 16h 39m
- Merged PRs (30d)
- 131
Description
`conformance_candidate_infos` keeps a member when `has_identifier(member) || is_operator_function(member)`. A conversion function `operator T()` has no identifier and `is_operator_function` is false for it, so it is dropped before conformance or rejection ever sees it:
```cpp
struct I { int f() const; explicit operator bool() const; };
struct C { int f() const { return 0; } }; // no operator bool
static_assert(is_protocol_conformant_v); // passes
protocol p{C{}}; // builds
static_cast(p); // ill-formed even if C did declare operator bool
```
So an interface author can put a conversion in the contract, have a type without it accepted, and find out at the call site. This predates #388, but #388 established the rule that every non-forwardable operator throws from `protocol_interface_function_infos` with a message naming it, and conversions are now the only category outside that rule.
Options: reject them there with the same style of diagnostic, forward them (they are nullary and const-qualifiable, so the machinery is close), or document the gap.
Contributor guide
Assessment
This issue has not been assessed yet.