Extend operator support

[jbcoe]

Extend operator forwarding support to more overloadable operators. operator=, operator co_await, the comparison operators, explicit-object members and unary operator& are rejected on an interface.

Fixes a self-assignment bug: protocol's copy/move assignment used this == &other, which a forwarded operator& would hijack; now uses std::addressof.

We opted not to use macros to reduce code verbosity. The limits of C++26 reflection mean that some boilerplate structure for operator thunks is somewhat repetitive.

[codecov]

Codecov Report

❌ Patch coverage is 99.39210% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.97%. Comparing base (3705d23) to head (82cce94).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
vtable.hh	33.33%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #388      +/-   ##
==========================================
+ Coverage   74.48%   80.97%   +6.49%     
==========================================
  Files          15       15              
  Lines        1011     1277     +266     
  Branches      224      214      -10     
==========================================
+ Hits          753     1034     +281     
+ Misses         49       44       -5     
+ Partials      209      199      -10     

Flag	Coverage Δ
consteval	89.81% <100.00%> (+4.64%)	⬆️
runtime	79.17% <99.26%> (+7.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[philipcraig]

Forwarding unary operator& breaks protocol's own assignment. The self-assignment checks at protocol.hh:413 and :439 spell &other, which now resolves to the interface's operator& thunk:

struct I { int operator&() const; int f() const; };
struct T { int operator&() const { return 99; } int f() const { return 3; } };
protocol<I> p{T{}}, q{T{}};
q = p;             // protocol.hh:413: comparison between pointer and integer
q = std::move(p);  // protocol.hh:439: same
auto r = &p;       // int, 99

If the interface's operator& returned a pointer the assignment would compile and compare this against the thunk's result, so genuine self-assignment falls through to destroy-then-copy-from-destroyed. std::addressof(other) at both sites fixes the wrappers (protocol.hh already uses it at 527 and 622). Whether &p on a wrapper should ever dispatch to the interface is a separate decision; at minimum it wants a sentence in the docs. Fine as a follow-up if you prefer.

CONTRIBUTING.md:194-196 still says no operators other than operator() are supported, and DRAFT.md:565-570 still says equality and comparison operators are not generated. Both need updating, or DRAFT.md needs a note that the reference implementation has diverged.

Inline comments cover the comparison-operator regression, a latent explicit-object mangling bug, and some duplication. Any of these can go to follow-up PRs; none needs to hold this one.

[jbcoe]

Thanks for the detailed review. All should be good to go now.

[philipcraig]

Two new things since last round, both filed as issues so they can be handled here or after:

• #400: call_through_vtable in vtable.hh only uses protocol_object inside the assert, so the installed header fails under -DNDEBUG -Wall -Wextra -Werror with unused parameter 'protocol_object'. main is clean under the same flags. CI has no -Wextra, so it stays green. [[maybe_unused]] fixes it.
• #401: rejecting ==/<=> turned a member comparison on the interface from silently ignored (what main does and DRAFT.md still says) into a hard consteval throw, so interfaces that compile on main stop compiling, including the = default idiom. Options are in the issue.

Docs still saying the old thing: protocol.hh:32 ("Neither implementation currently supports operators other than operator()"), DRAFT.md:152-154 (protocol does not provide operator* or operator->) and DRAFT.md:565-567 (member comparisons "are not generated"). The protocol.hh line is a one-word fix; the DRAFT.md ones can wait for #396 if that is imminent.

#403: operator new/delete on an interface are dropped by the is_static_member skip with no diagnostic, while the new mangling tests assert codes for them. Probably intended, so a docs decision rather than a code one.

The rest are inline and each points at an issue (#402, #404, #405, #406, #407). Nothing here blocks merging.

[philipcraig]

#400: protocol_object is only used inside the assert, so with NDEBUG this is -Werror=unused-parameter in an installed header. [[maybe_unused]] here; the issue also notes the -O0 cost of the helper not being inline.

[philipcraig]

#401: on main a member operator== on the interface was silently ignored; this makes it a hard error, so

struct I { int f() const; bool operator==(const I&) const = default; };

no longer compiles against any candidate. There is also no rejection test for any of the seven comparisons; UnsupportedOperatorsAreRejected covers = and co_await only.

[philipcraig]

#402: operator T() has no identifier and is_operator_function is false for it, so conversion functions fall out here before conformance or rejection sees them. A candidate without the conversion conforms, and static_cast<bool>(p) is ill-formed even when both sides declare it. Pre-existing, but this is now the only operator category that neither forwards nor throws.

[philipcraig]

#406: this name expression is a copy of the one eight lines up, and operator_diagnostic_name below renders names a third way (no overload, no parameter list). Hoisting name once and nesting the two operator checks under a single if (is_operator_function(member)) removes the duplication and gives every rejection the same wording.

[philipcraig]

#407: The deleted Limitations bullet carried four statements that are still true and are now documented nowhere: member function templates are not matched (#393), the generated wrapper does not apply an interface member's ref-qualifier (#356), there is no conversion between wrappers of different interfaces, and conformance checking is O(N*M). They should come back, though they never really belonged in a contributing guide; the issue proposes a doc/limitations.md that this bullet links to, which can also list what #388 rejects. The Supported Features bullet above still names only operator().

[philipcraig]

#404: from here down each test declares its own Interface/Conforming pair and instantiates all three wrapper kinds, about 132 define_aggregate generations for the TU. It is roughly 3 s of instantiation in every job that builds the tests; one shared interface per operator family halves it in a matched experiment. Test-structure optimisation only, no design question.

[philipcraig]

#405: third copy of this builder, after member_function_thunk_for::fn_ptr_type() and the inline one in generate_vtable_specs. vtable.hh's copy already differs (dealias on parameter types, relevant to #397); all three must agree for the thunk specialisation to match the vtable entry. One function_pointer_type_of(info) in vtable.hh would serve all three.