Issue 2516: [fund.ts.v2] Public "exposition only" members in observer

This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of TS status.

2516. [fund.ts.v2] Public "exposition only" members in `observer_ptr`

Section: 8.12.1 [fund.ts.v2::memory.observer.ptr.overview] Status: TS Submitter: Tim Song Opened: 2015-07-07 Last modified: 2017-07-30

Priority: 2

View all issues with TS status.

Discussion:

Addresses: fund.ts.v2

In N4529 [memory.observer.ptr.overview], the public member typedefs pointer and reference are marked "//exposition-only".

Clause 17 of the standard, which the TS incorporates by reference, only defines "exposition only" for private members (see 16.3.3.5 [objects.within.classes], also compare LWG 2310). These types should be either made private, or not exposition only.

[2015-07, Telecon]

Geoffrey: Will survey "exposition-only" use and come up with wording to define "exposition-only" for data members, types, and concepts.

[2015-10, Kona Saturday afternoon]

GR: I cannot figure out what "exposition only" means. JW explained it to me once as meaning that "it has the same normative effect as if the member existed, without the effect of there actually being a member". But I don't know what is the "normative effect of the existence of a member" is.

MC: The "exposition-only" member should be private. GR: But it still has normative effect.

GR, STL: Maybe the member is public so it can be used in the public section? WEB (original worder): I don't know why the member is public. I'm not averse to changing it. GR: A telecon instructed me to find out how [exposition-only] is used elsewhere, and I came back with this issue because I don't understand what it means.

STL: We use exposition-only in many places. We all know what it means. GR: I don't know precisely what means.

STL: I know exactly what it means. STL suggests a rewording: the paragraph already says what we want, it's just a little too precise. GR not sure.

WEB: Are there any non-members in the Standard that are "exposition only"? STL: DECAY_COPY and INVOKE.

GR: There are a few enums.

HH: We have nested class types that are exposition-only. HH: We're about to make "none_t" an exposition-only type. [Everyone lists some examples from the Standard that are EO.] GR: "bitmask" contains some hypothetical types. That potentially contains user requirements (since regexp requires certain trait members to be "bitmask types").

STL: What's the priority of this issue? Does this have any effect on implementations? Is there anything mysterious that could happen?

AM: 2.

STL: How did that happen? It's at best priority 4. We have so many better things we could be doing.

WEB: "exposition only" in [???] is just used as plain English, not as words of power. GR: That gives me enough to make wording to fix this.

STL: I wouldn't mind if we didn't fix this ever.

MC: @JW, please write up wording for 2310 to make the EO members private. JW: I can't do that, because that'd make the class a non-aggregate.

WEB: Please cross-link both issues and move 2516 to "open".

[2015-11-14, Geoffrey Romer provides wording]

[2016-03 Jacksonville]

Move to ready. Note that this modifies both the Draft Standard and LFTS 2

Proposed resolution:

This part of the wording is against the working draft of the standard for Programming Language C++, the wording is relative to N4567.
1. Edit 16.3.3.5 [objects.within.classes]/p2 as follows:
  -2- ~~Objects of certain classes are sometimes required by the external specifications of their classes to store data, apparently in member objects.~~ For the sake of exposition, some subclauses provide representative declarations, and semantic requirements, for private members ~~objects~~ of classes that meet the external specifications of the classes. The declarations for such members ~~objects and the definitions of related member types~~ are followed by a comment that ends with exposition only, as in:
```
streambuf* sb; // exposition only
```

This part of the wording is against the working draft of the C++ Extensions for Library Fundamentals, Version 2, the wording is relative to N4529

Edit the synopsis in 8.12.1 [fund.ts.v2::memory.observer.ptr.overview] as follows:

namespace std {
namespace experimental {
inline namespace fundamentals_v2 {

  template <class W> class observer_ptr {
    using pointer = add_pointer_t<W>;            // exposition-only
    using reference = add_lvalue_reference_t<W> // exposition-only
  public:
    // publish our template parameter and variations thereof
    using element_type = W;
    using pointer = add_pointer_t<W>;            // exposition-only
    using reference = add_lvalue_reference_t<W> // exposition-only

    // 8.12.2, observer_ptr constructors
    // default c'tor
    constexpr observer_ptr() noexcept;

    […]
  }; // observer_ptr<>

} // inline namespace fundamentals_v2
} // namespace experimental
} // namespace std

2516. [fund.ts.v2] Public "exposition only" members in observer_ptr

2516. [fund.ts.v2] Public "exposition only" members in `observer_ptr`