P1255 R13 A view of 0 or 1 elements: views::nullable And a concept to constrain maybes

[jensmaurer]

P1255R1 A view of 0 or 1 elements: view::maybe (Steve Downey)

[jensmaurer]

P1255R2 A view of 0 or 1 elements: view::maybe (Steve Downey)

[wg21bot]

P1255R3 A view of 0 or 1 elements: view::maybe (Steve Downey)

[wg21bot]

P1255R4 A view of 0 or 1 elements: view::maybe (Steve Downey)

[brycelelbach]

Kona 2019-02 LEWGI Minutes

P1255R2 std::view::maybe

Champion: Steve Downey

Minute Taker: Guy Davidson

Start Overview: 8:10

Start Discussion: 8:32

Is a function pointer Nullable?

Should a pointer to uninitialized memory satisfy the semantics of it.

Add maybe_view?

Start Polling: 8:55

POLL: When we ship std::view::maybe, Nullable should be a normative concept, knowing that our time is scarce and this will leave less time for other work.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
1	4	4	3	0

Attendance: 15

POLL: std::view::maybe’s reference capture semantics should be consistent with std::view::single.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
4	2	5	1	0

Attendance: 15

Volunteers to Help Write Wording: Nathan Myers, Alisdair Meredith (post meeting), Matt Calabrese (post meeting)

End: 8:58

CONSENSUS: Bring a revision of P1255R2, with the guidance below, to LEWGI for further design review.

• Add wording.
• Add a Nullable named type requirement.
• Make std::view::maybe's reference capture semantics consistent with std::view::single.

[brycelelbach]

Cologne 2019-07 LEWGI Minutes

P1255R4 std::view::maybe: Design Review

Champion: JeanHeyd Meneide

Minute Taker: Phillip Ratzloff

Start Overview: 07-18 8:44

Add tony tables for LEWG.

Start Review: 9:00

Start Polling: 9:12

• Fix the typo'd maybe_view constructor outside of the maybe_view; it should be the factory function maybe.
• s/semiregularbox/semiregular-box/.
• Remove conditional noexceptness from the constructors (consistent with single_view), and call LEWG's attention to this.
• Use unwrap_ref instead of the exposition-only maybe_unwrap.
• Call LEWG's attention to the use of ptrdiff_t as the return type of size (which is consistent with single_view).
• s/is_reference_wrapper/is_reference_wrapper_v/.

POLL: We should promise more committee time to pursuing P1255R4, with the guidance above, and forward it to LEWG for C++23, knowing that our time is scarce and this will leave less time for other work.

NO OBJECTION TO UNANIMOUS CONSENT.

Attendance: 13

End: 9:16

CONSENSUS: LEWGI sends P1255R4, with the guidance below, to LEWG, for C++23.

• Fix the typo'd maybe_view constructor outside of the maybe_view; it should be the factory function maybe.
• s/semiregularbox/semiregular-box/.
• Remove conditional noexceptness from the constructors (consistent with single_view), and call LEWG's attention to this.
• Use unwrap_ref instead of the exposition-only maybe_unwrap.
• Call LEWG's attention to the use of ptrdiff_t as the return type of size (which is consistent with single_view).
• s/is_reference_wrapper/is_reference_wrapper_v/.

[wg21bot]

P1255R5 A view of 0 or 1 elements: views::maybe (Steve Downey)

[brycelelbach]

P1255R6: std::views::maybe

2020-04-06 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Steve Downey

Minute Taker: Ben Craig

Start Review: 2020-04-06 08:13

Add before/after tables.

Add an example where the pipeline uses reference semantics instead of copy
semantics.

Look at codegen differences of the before/after examples.

Should the design strive to be consistent with views::single and
views::empty?

Supports reference_wrapper; should it?

Two things here:

• Exposition-only nullable concept.
• std::views::maybe.

Should iterators be nullable?

Consider making std::views::maybe model nullable itself?

• If we do this it may subsume the proposals for observer_ptr.
• All that needs to be added is operator*.

nullable doesn't support fancy pointers.

Example: bit_reference stuff from Ranges TS.

noexceptness of constructors.

Replace iter_reference_t with its definition to avoid confusion.

Should nullable be exposition only?

Make it clearer that nullable is exposition only. Look for precedence.

There's an odd symbol under the wording for size.

POLL: The first version of std::views::maybe should support proxy reference
types.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
1	7	11	2	0

Attendance: 27

# of Authors: 1

Author Position: N

That has consensus in favor.

std::pointer_traits may be the the right way to do addressof for proxy
pointers and references.

Const propagation - if we pass a int* to std::views::maybe, what const
semantics should we get?

Today, it is "shallow const", not "deep const", which is consistent with
std::views::single with regards to const propagation.

Tomasz suggests different const propagation semantics for different things.

Generally, it seems people are saying:

• "deep const" makes sense for optional/expected.
• "shallow const" makes sense for pointers.

Right now, std::views::maybe owns the underlying thing if it's not a
std::reference_wrapper.

Maybe we ought to have two versions: maybe (which owns) and maybe_ref
(which does not own).

POLL: We want both a std::views::maybe (which owns the underlying
nullable) and a std::views::maybe_ref (which holds a pointer to the
underlying nullable).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	5	6	2	2

Attendance: 24

# of Authors: 1

Author Position: WF

That has no consensus.

POLL: std::views::maybe should support std::reference_wrapper.__

NO OBJECTION TO UNANIMOUS CONSENT.

Attendance: 24

Adding std::reference_wrapper support to std::views::single should be
considered, but as a separate paper.

POLL: std::views::maybe should model std::ranges::borrowed_range if it's
not holding the object by value.

NO OBJECTION TO UNANIMOUS CONSENT.

Look at P2017: Conditionally Borrowed Ranges.

Add a const propagation section discussing options, existing precedence, and
proposing the option that the author suggests

POLL: Add operator* to std::views::maybe, which will make it satisfy the
nullable concept.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
0	1	2	11	4

Attendance: 24

# of Authors: 1

Author Position: WA

That has consensus against.

We don't want std::views::maybe to model nullable.

End: 09:52

CONSENSUS: Bring a revision of P1255R1 (std::views::maybe), with the
guidance below, to Library Evolution for further design review.

• Add before/after tables.
• Add an example where pipelines use references.
• Add support for proxy references (explore std::pointer_traits, etc).
• Make std::views::maybe model std::ranges::borrowed_range if it's not
  holding the object by value.
• Add a const propagation section discussing options, existing precedence,
  and proposing the option that the author suggests.
• Consider writing a separate paper proposing the addition of
  std::reference_wrapper support to std::views::single.

[wg21bot]

P1255R8 A view of 0 or 1 elements: views::maybe (Steve Downey)

[wg21bot]

P1255R9 A view of 0 or 1 elements: views::maybe (Steve Downey)

[billy-baker]

2022-08-30 Library Evolution Telecon

P1255R9: views::maybe

2022-08-30 Library Evolution Telecon Minutes

Chair: Billy Baker

Minute Taker: Inbal Levi

Champion: Steve Downey

POLL: We should promise more committee time to pursuing P1255 (A view of 0 or 1 elements: views::maybe), knowing that our time is scarce and this will leave less time for other work.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
1	5	2	0	2

Attendance: 14

# of Authors: 1

Author Position: SF

Outcome: Consensus to continue spending time on P1255.

SA: Better ways to solve the problem such as a filter_transform algorithm.

Next Steps

Author has some more homework and will bring back another revision. The definition of the nullable_object concept was missing from R9. There are some wording issues related to duplicated text. There is some concern that novice users will see more complexity in the provided examples.

[wg21bot]

P1255R10 A view of 0 or 1 elements: views::maybe (Steve Downey)

[inbal2l]

2024-01-09 Library Evolution Telecon

D1255R11: A view of 0 or 1 elements: views::maybe

2024-01-09 Library Evolution Telecon Minutes

Champion: Steve Downey

Chair: Inbal Levi

Minute Taker: Ben Craig

Summary

POLL: We would like to hold the “views::maybe” utility in the proposal P1255R11 and see a paper in the next meeting exploring the direction of modifying std::optional to behave like a range (add begin, end)

SF	F	N	A	SA
3	4	2	5	1

Attendance: 19
# of Authors: 1
Author's Position: SA
Outcome: No consensus

POLL: We would like to add “views::maybe” to the standard library

SF	F	N	A	SA
4	7	1	3	1

Attendance: 19
# of Authors: 1
Author's Position: SF
Outcome: Consensus in favor

POLL: We would like to add “views::nullable” to the standard library

SF	F	N	A	SA
7	9	0	0	0

Attendance: 19
# of Authors: 1
Author's Position: SF
Outcome: Strong consensus in favor

To summarize the polls: seems like the room is not in favor of removing it now, but if a paper comes up advocating for removing “views::maybe” in favor of having fewer vocabulary types, we will prioritize scheduling that paper, as it is a fix (B2).

The following should be updated by the next time LEWG sees the paper:

1. Add definitions of the exposition-only concepts "nullable_object", "nullable_object_val" and "nullable_object_ref" in the paper. Finalize names in the LEWG mailing list.
2. Get input from LWG on whether the exposition-only "maybe_view" member: "std::optionalvalue_; // exposition only" can be represented by a movable_box to allow more implementation freedom (NOTE: This will also effect the return values from the member functions)
3. (if possible) Add history and/or rationale on the design direction of adding begin/end to std::optional (note that the polls suggest LEWG don't consider this as blocking)
4. Add rationale to the monad function (or remove them)
5. Circle the results for previous sections with Kirk, David, Anthony, and anyone else who showed interest.

Next Steps

The author will add exploration to the paper as described above, LEWG will see the next draft revision once it's ready.

[wg21bot]

P1255R11 A view of 0 or 1 elements: views::maybe (Steve Downey)

[wg21bot]

P1255R12 A view of 0 or 1 elements: views::maybe (Steve Downey)

[wg21bot]

P1255R13 A view of 0 or 1 elements: views::nullable And a concept to constrain maybes (Steve Downey)

[inbal2l]

2024-03-20 Library Evolution Telecon Tokyo

P1255R12: A view of 0 or 1 elements: views::maybe

2024-03-20 Library Evolution Telecon Minutes

Champion: Steve Downey
Chair: Fabio Fracassi
Minute Taker: Guy Davidson

Summary

@todo by chair
(Please include important polls here in the following format)

POLL: We want std::views::maybe even if we get both P3168 (optional conforms to range) and P2988 (optional<T&>) into the standard.

SF	F	N	A	SA
1	1	5	9	6

Attendance: 18 + 8
Author's Position: 1
Outcome: Consensus against

SF: I love the minimal/safer interface.

A: I think that more important than anything we want to make sure that we can compose things together nicely and cleanly and I’m a bit concerned with returning a pointer of optional range.

Next Steps

std::views_maybe was not supported, the paper should be seen again in LEWG to consider other aspects:

• std::maybe concept.
• Free functions on maybe types such as optional and pointers.