Require exact return-type matches in generated protocol concepts (1/20)

[jbcoe]

protocol.j2's generated concepts used std::convertible_to, letting
merely-convertible return types conform; switched to std::same_as
per DRAFT.md's exact-match design. CovariantBImpl no longer conforms
to B and moves from a dispatch test to a negative static_assert.

[RyanJK5]

I think whether or not this is the right direction depends on what protocol wants consistency with. For example, std::function allows convertible return types:

double f() { return 1.5; }

int main() {
    return std::function<int()>{f}(); // OK, returns 1
}

But virtual functions do not. They do allow covariant returns, though:

struct A {
    virtual A& foo() = 0;
};

struct B : A {
    B& foo() override; // OK
};

Which might be analogous to:

struct Interface {
    protocol_view<Interface> foo();
};

struct S {
    S& foo();
};

What is the rationale here for protocol's design?

[jbcoe]

For now I'm keen to implement what's in the DRAFT.md and this is one area that we've been explicit about:

---

Relaxed structural subtyping

We require a type to have exactly matching function signatures as I to be considered a
conforming type for protocol<I>. Implicit conversions could be allowed but this might
lead to odd chains of implicit-conversion-led conformance where an object can be passed
through a sequence of protocol (or protocol_view) objects to conform to the interface
of the last protocol. Where implicit conversions are unidirectional this may lead to
undesirable or surprising behaviour.

With some suitably compelling motivation, conformance via implicit conversions could be
added to protocol in a later revision of the C++ standard without rendering existing code
ill-formed.

---

The strongest argument for picking this option is that it's the one that lets us change our minds later without breaking code. This approach served us well for indirect and polymorphic.

With suitable motivation, I'm happy to change this part of the design, but we should land the reflection implementation of DRAFT first. I raised #121 to track this.

[RyanJK5]

For now I'm keen to implement what's in the DRAFT.md and this is one area that we've been explicit about:

Relaxed structural subtyping

We require a type to have exactly matching function signatures as I to be considered a conforming type for protocol<I>. Implicit conversions could be allowed but this might lead to odd chains of implicit-conversion-led conformance where an object can be passed through a sequence of protocol (or protocol_view) objects to conform to the interface of the last protocol. Where implicit conversions are unidirectional this may lead to undesirable or surprising behaviour.

With some suitably compelling motivation, conformance via implicit conversions could be added to protocol in a later revision of the C++ standard without rendering existing code ill-formed.

The strongest argument for picking this option is that it's the one that lets us change our minds later without breaking code. This approach served us well for indirect and polymorphic.

With suitable motivation, I'm happy to change this part of the design, but we should land the reflection implementation of DRAFT first. I raised #121 to track this.

That makes a lot of sense, thank you!