Add explicit discussion of generated member functions#60
Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the WG21 draft proposal document to add an explicit foreword and a new section describing how protocol / protocol_view generate member functions from an interface type.
Changes:
- Add a new “Foreword” section describing the early-stage status and intent of the proposal.
- Replace the previous “Examples” placeholder with a “Generated structural subtyping” section and illustrative code snippets.
- Add a short note about current reference-implementation code generation vs. potential compiler/static-reflection approaches.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ## Foreword | ||
|
|
||
| This is a very early stage design which we are sharing to further discussion |
There was a problem hiding this comment.
Foreword wording is ungrammatical: “sharing to further discussion” should be “sharing to further the discussion” (or similar).
| This is a very early stage design which we are sharing to further discussion | |
| This is a very early stage design which we are sharing to further the discussion |
| For a given struct, the corresponding `protocol` and `protocol_view` will | ||
| implement all the public non-virtual, non-template member functions with | ||
| identical constexpr, noexcept and const-qualification. | ||
|
|
There was a problem hiding this comment.
This section says generated members have “identical constexpr, noexcept and const-qualification”, but the example doesn’t match (e.g., I::func1(double) is non-const while the generated func1 shown is const). Either adjust the claim or fix the example signatures to keep const-qualification identical.
| template <typename Allocator> | ||
| class protocol<I, Allocator=std::allocator<void>> { |
There was a problem hiding this comment.
The shown specialization class protocol<I, Allocator=std::allocator<void>> isn’t valid C++ syntax for a partial specialization (default arguments belong on the template parameter, and the specialization argument list shouldn’t assign). Consider writing it as template <typename Allocator = std::allocator<void>> class protocol<I, Allocator> { ... } (or equivalent).
| template <typename Allocator> | |
| class protocol<I, Allocator=std::allocator<void>> { | |
| template <typename Allocator = std::allocator<void>> | |
| class protocol<I, Allocator> { |
| ```c++ | ||
| template <typename Allocator> | ||
| class protocol_view<I> { | ||
| // Constructors - see technical specification below. |
There was a problem hiding this comment.
protocol_view is presented as having an Allocator template parameter here (template <typename Allocator> class protocol_view<I>), but elsewhere in the document (and in the reference implementation) protocol_view only takes the interface type. This example should be a full specialization (template <> class protocol_view<I> { ... }) without an allocator parameter.
| ``` | ||
|
|
||
| ```c++ | ||
| template <typename Allocator> |
There was a problem hiding this comment.
Same issue as above for protocol_view<const I>: it’s shown as template <typename Allocator> but should be a full specialization of protocol_view (no allocator template parameter).
| template <typename Allocator> |
| ### Minimal API examples | ||
| // structural-subtype const member functions. | ||
| std::string func0(std::string_view) const noexcept; | ||
| double func1(double) const; |
There was a problem hiding this comment.
In the protocol_view<const I> example, func1(double) const is listed even though I::func1(double) in the interface example is non-const. If protocol_view<const T> only exposes const-qualified interface functions, this should likely only include func0(...) const noexcept (and omit non-const members like func1/func2).
| double func1(double) const; |
| ## Foreword | ||
|
|
||
| This is a very early stage design which we are sharing to further discussion | ||
| of design differences with a series of competing proposals for structural-subtyping. |
There was a problem hiding this comment.
Terminology is inconsistent here: the rest of the draft uses “structural subtyping” (no hyphen), but this sentence uses “structural-subtyping”. Consider making it consistent with the rest of the document.
| of design differences with a series of competing proposals for structural-subtyping. | |
| of design differences with a series of competing proposals for structural subtyping. |
No description provided.