Prague 2020-01 LEWGI Minutes

P1950R0 std::indirect_value: Direction Review

Chair: Bryce Adelstein Lelbach

Champion: Antony Peacook

Minute Taker: Ben Craig

Start Review: 2020-02-10 16:10

What should default constructing an indirect_value do? Default initialize a T, or initialize the indirect_value to some empty state?

Should indirect_value have a nullable state?

Use cases for this:

• PIMPL objects that you want to use with value semantics.
• You have something heap-allocated that you want to manipulate with value semantics.

Should this have a comparison operator, and what does it mean?

Does this model a pointer or a value? Is that the right question?

• It's supposed to behave like a pointer that deep copies.

Variadic constructor needs to be looked at, R0 uses new.

Start Polling: 16:49

POLL: We should promise more committee time to pursuing P1950R0 (std::indirect_value), knowing that our time is scarce and this will leave less time for other work.

Attendance: 20

# of Authors: 2

Author Position: SF

POLL: indirect_value should have a nullable state (which implies that the move constructor and move assignment operator are cheap, can be noexcept, and that operator* and operator-> have a narrow contract).

Attendance: 19

# of Authors: 2

Author Position: SF

A (x2): PIMPL should never be null.

End: 17:02

CONSENSUS: Bring a revision of P1950R0 (std::indirect_value), with the guidance below, to LEWGI for further design review.

• Document that LEWGI had consensus for indirect_value having a nullable state.
• Discuss comparisons/contrasts/interactions with optional.
• Add a table describing the ways/properties in which unique_value, unique_ptr, and polymorphic_value differ.
• Add a section (perhaps an FAQ) that clears up any confusion about the mental model
  • Perhaps an FAQ section that addresses the question "does indirect_value model a point or a value?". My impression was that the answer is "neither, that's not really the right question". explaining why in the paper may help down the road.
• Strengthen motivation:
  • Enumerate all the major use cases.
    • Add any data that you have about how widespread the use cases are.
  • Add a code example for each use case (before/after tables recommended).
  • Add a list of links to prior art - e.g. similar constructs in the wild. Ideally, these would be things that are widely used and publicly available/documented.
• Address open questions regarding allocator support.
  • Figure out a story for allocator support for the variadic constructor.
  • Adding an allocate_indirect_value/allocator_copy/allocator_delete similar to P0316 allocate_unique might be the answer.

Prague 2020-02 LEWGI Minutes

D1950R1 std::indirect_value Direction Review

Chair: Ryan McDougall

Champion: Antony Peacock, Jonathan Coe

Minute Taker: Thomas Köppe

Start Review: 2020-02-12 13:44

Examples: Yes, in paper.

Implementation experience: Yes, on GitHub, in paper.

Usage experience: Yes.

Prior art: Yes, in paper.

Wording: Yes in paper.

Comparison with unique_ptr: Yes, in paper:

• indirect_value supports copyable objects.
• Copying indirect_value has deep copy semantics.
• indirect_value propagates const.

If you want something like unique_ptr for copyable objects, why not just standardize that or use shared_ptr? Answer: This has deep copy semantics.

Do we need both the variadic constructor that uses new/default_delete/default_copy and make_indirect_value?

Do we want indirect_value<T[]>.

Start Polling: 14:12

POLL: We should promise more committee time to pursuing D1950R1 (std::indirect_value) and forward it to LEWG for C++23, knowing that our time is scarce and this will leave less time for other work.

Attendance: 20

# of Authors: 2

Author Position: SF

That has unanimous consent.

End: 14:15

CONSENSUS: LEWGI sends D1950R1 (std::indirect_value) to LEWG for C++23.

P1950R1 An indirect value-type for C++ (Jonathan Coe, Antony Peacock)

Attaching a summary of the suggestions and highlighted topics from LEWG Mailing list review on R1 (ended on 2020-12-14), to be addressed to on R2 / follow-up paper:

1. Examples improvements: add an example demonstrating const propagation.
2. Structure related comments:

• Interaction of polymorphic_value indirect_value will be explored in a future paper (polymorphic_value's behaviour should be consistent with indirect_value).
  explicit indirect_value(T* p, C c=C{}, D d=D{}); should be changed into
  explicit indirect_value(T* p);
  explicit indirect_value(T* p, C c, D d);empty state:

• LEWGI's direction: for an empty state, implying narrow contracts for operators * and ->:
  (|SF|WF|N|WA|WF| 7 | 3 | 5 | 1 | 1 |). Authors are open for discussion on this. Naming is aligned with polymorphic_value.  

• constructing from T: is done by the inplace constructor, to avoid accidental construction from a value.

• make_indirect_value uses U for SFINAE, proposal will be updated to use concepts & constraints. 
  Notice: "Requires" doesn't exist anymore.  Please split into "Mandates", "Constraints" and "Preconditions" as appropriate. requirements on copier and deleter seem to be missing. 

• Explore the preferred behaviour regarding SBO. Suggested option:
  prohibit it, to avoid invalidating pointers/refes by move:
  void test(indirect_value iv) {
      auto *p=&*iv;
      auto copy=std::move(iv);
      assert(p==&*copy);  // i.e., using p is valid
   }
   (In fact, this is exactly how we would specify no SBO.)  

• indirect_value supports taking a Deleter (and using std::default_delete<T>), does not share the same API design as std::unique_ptr where the managed type is only a T* if the Deleter does not contain a ::pointer alias. 

• Interface refers to "if custom deleter and copier", please see the thread for fixes.

3. Wording comments:

• Please make sure that library description elements are ordered canonically (see [structure.specifications] for the canonical order)  
• Please add a comma before "or bad_alloc" to clarify conditions.
• Please replace the term "CopyConstructible", it is not in use on C++20.  
• indirect_value& operator=(const indirect_value& p); "the copy is created by the copier in p" Please align with standard wording. 

Closing due to more than 1 year of inactivity. Please re-open if further work is expected.

This paper/issue is superseded by #1680