Title
p0083r3 node_handle private members missing "exposition only" comment
Status
c++23
Section
[container.node.overview]
Submitter
Richard Smith

Created on 2016-07-08.00:00:00 last changed 4 months ago

Messages

Date: 2020-11-09.21:40:50

Proposed resolution:

This wording is relative to N4810.

  1. Change [container.node.overview], exposition-only class template node-handle synopsis, as indicated:

    template<unspecified>
    class node-handle {
    public:
      […]
    private:
      using container_node_type = unspecified; // exposition only
      using ator_traits = allocator_traits<allocator_type>; // exposition only
      typename ator_traits::template rebind_traits<container_node_type>::pointer ptr_; // exposition only
      optional<allocator_type> alloc_; // exposition only
    
    public:
      […]
    };
    
Date: 2020-11-09.00:00:00

[ 2020-11-09 Approved In November virtual meeting. Status changed: Tentatively Ready → WP. ]

Date: 2020-05-16.00:00:00

[ 2020-05-16 Reflector discussions ]

Status to Tentatively Ready after five positive votes on the reflector.

Date: 2019-03-15.00:00:00

[ 2019-03-17; Daniel comments and provides wording ]

Due to an editorial step, the previous name node_handle/node_handle has been replaced by the artificial node-handle name, so I see no longer any reason to talk about a name node_handle reservation. The provided wording therefore only takes care of the private members.

Date: 2016-08-01.18:34:48

[ 2016-07 Chicago ]

Jonathan says that we need to make clear that the name node_handle is not reserved

Date: 2016-07-08.00:00:00

The private members of node_handle are missing the usual "exposition only" comment. As a consequence, ptr_ and alloc_ now appear to be names defined by the library (so programs defining these names as macros before including a library header have undefined behavior).

Presumably this is unintentional and these members should be considered to be for exposition only.

It's also not clear whether the name node_handle is reserved for library usage or not; [container.node.overview]/3 says the implementation need not provide a type with this name, but doesn't seem to rule out the possibility that an implementation will choose to do so regardless.

Daniel:

A similar problem seems to exist for the exposition-only type call_wrapper from p0358r1, which exposes a private data member named fd and a typedef FD.

History
Date User Action Args
2023-11-22 15:47:43adminsetstatus: wp -> c++23
2020-11-09 21:40:50adminsetmessages: + msg11552
2020-11-09 21:40:50adminsetstatus: ready -> wp
2020-05-16 16:34:59adminsetmessages: + msg11296
2020-05-16 16:34:59adminsetstatus: new -> ready
2019-03-17 18:39:51adminsetmessages: + msg10363
2019-03-17 18:39:51adminsetmessages: + msg10362
2016-08-01 18:34:48adminsetmessages: + msg8281
2016-07-08 00:00:00admincreate