Conversation
There was a problem hiding this comment.
Pull request overview
Updates proposal wording in DRAFT.md, focusing on tightening the specification of protocol_view construction to avoid accidental binding to temporaries.
Changes:
- Removes previously commented-out draft wording for
swapand allocator support. - Adds deleted rvalue constructor overloads for
protocol_view/protocol_view<const I>to prevent dangling from temporaries. - Rewords several constructor/assignment/member-access clauses to describe “stored reference” semantics.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ``` | ||
|
|
||
| 4. _Preconditions_: protocol `p` is not valueless. | ||
| 4. _Preconditions_: protocol `p` is not valueless after move. |
There was a problem hiding this comment.
In [protocol_view.ctor], the item numbering becomes inconsistent after adding the deleted rvalue overloads (e.g., repeats "4." and then jumps to "6."/"7." with no "5."). Please renumber the Preconditions/Effects/Remarks items so the list is strictly increasing and unambiguous.
| 4. _Preconditions_: protocol `p` is not valueless after move. | |
| 5. _Preconditions_: protocol `p` is not valueless after move. |
| ``` | ||
|
|
||
| 4. _Preconditions_: protocol `p` is not valueless. | ||
| 4. _Preconditions_: protocol `p` is not valueless after move. |
There was a problem hiding this comment.
In [protocol_view.const.ctor], numbering is inconsistent after the new deleted rvalue overloads (e.g., "4. Preconditions" appears again after "4. Remarks", then jumps to "6."/"9."/"10."). Please renumber the items across this subclause to avoid duplicate or skipped item numbers.
| 4. _Preconditions_: protocol `p` is not valueless after move. | |
| 5. _Preconditions_: protocol `p` is not valueless after move. |
| 1. For each public non-static, non-template member function _f_ declared in _I_, `protocol_view<I>` shall contain a public non-virtual member function with an identical signature as specified in [protocol.member.access]. For `protocol_view<const I>`, only the member functions of _I_ that have a `const` cv-qualifier are provided. | ||
|
|
||
| 2. _Preconditions_: `data_` does not equal `nullptr`. | ||
| 2. _Preconditions_: The stored reference is not null and refers to a valid object. |
There was a problem hiding this comment.
"The stored reference is not null" is internally inconsistent: references cannot be null. Either describe the representation as storing a pointer (and keep a non-null precondition), or reword the precondition to only require that the referenced object remains valid for the view’s lifetime.
| 2. _Preconditions_: The stored reference is not null and refers to a valid object. | |
| 2. _Preconditions_: The referenced object is valid. |
| constexpr protocol_view(const protocol_view&) noexcept = default; | ||
|
|
||
| constexpr protocol_view& operator=(const protocol_view&) noexcept = default; | ||
| private: | ||
| const I* data_; // exposition only | ||
| //private: | ||
| //void* object_ptr_; // exposition only | ||
| //const void* dispatch_table_; // exposition only | ||
| }; |
There was a problem hiding this comment.
The synopsis now has the representation for protocol_view<const I> commented out (including the private: label), and protocol_view<I> no longer shows any exposition-only state. This makes later wording like "stored reference"/member-access preconditions harder to interpret. Consider restoring a consistent private: section with exposition-only members (as done for protocol in [protocol.syn]) or removing representation-dependent wording elsewhere.
| protocol_view(protocol_view<I>&&) = delete; | ||
| ``` | ||
|
|
||
| 13. _Remarks_: Rvalue references are deleted to prevent dangling references. |
There was a problem hiding this comment.
The remark for deleting protocol_view(protocol_view<I>&&) says it prevents dangling references, but moving/copying a protocol_view does not create a dangling reference to the underlying object (it still refers to the same object). Either adjust the rationale (if the intent is different) or consider allowing construction from an rvalue protocol_view<I> since it is effectively the same as copying.
| 13. _Remarks_: Rvalue references are deleted to prevent dangling references. | |
| 13. _Remarks_: This constructor is deleted to disallow initialization from temporary `protocol_view` objects. |
No description provided.