Skip to content

P2988R12 std::optional<T&> #7979

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

steve-downey
Copy link
Contributor

Fixes #7939
Fixes cplusplus/papers#1661

Note -- fixed a overfull hbox issue by forcing a break for the constraints at around 5469

is_reference_v ||
(is_move_constructible_v && is_swappable_v)
is true.

@steve-downey steve-downey requested a review from jensmaurer June 22, 2025 07:14
@tkoeppe
Copy link
Contributor

tkoeppe commented Jun 22, 2025

Thanks, @steve-downey, I can take it from here!

@tkoeppe tkoeppe force-pushed the motions-2025-06-lwg-2 branch 2 times, most recently from 28c97ee to c81e631 Compare June 22, 2025 12:16
\tcode{T} shall be a type
other than \cv{} \tcode{in_place_t} or \cv{} \tcode{nullopt_t}
that meets the \oldconcept{Destructible} requirements (\tref{cpp17.destructible}).
A type \tcode{X} is a \defnx{valid contained type}{valid contained type!\idxcode{optional}} for \tcode{optional} if \tcode{X} is an lvalue reference type
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's see if ISO lets us get away with this definition. If not, this is a local-enough term that we can just not mark it up, like we do elsewhere (e.g. shared_ptr's "empty").

@tkoeppe tkoeppe force-pushed the motions-2025-06-lwg-2 branch from c81e631 to b15b2ef Compare June 22, 2025 12:37
@steve-downey
Copy link
Contributor Author

Thanks, @steve-downey, I can take it from here!

I will keep an eye so as to improve the next one.

@tkoeppe tkoeppe force-pushed the motions-2025-06-lwg-2 branch 3 times, most recently from dee99a1 to bd3fcd7 Compare June 22, 2025 13:33
@tkoeppe tkoeppe force-pushed the motions-2025-06-lwg-2 branch from bd3fcd7 to f9fe472 Compare June 22, 2025 13:48
@tkoeppe tkoeppe requested a review from jensmaurer June 22, 2025 13:50
@tkoeppe tkoeppe requested review from jwakely and jensmaurer and removed request for jensmaurer June 22, 2025 13:50
@tkoeppe tkoeppe requested review from jensmaurer and removed request for jwakely and jensmaurer June 22, 2025 13:51
@tkoeppe tkoeppe added this to the post-2025-06 milestone Jun 22, 2025
@@ -4442,6 +4451,551 @@
\tcode{*this} does not contain a value.
\end{itemdescr}

\rSec2[optional.optional.ref]{Partial specialization of \tcode{optional} for reference types}

\rSec3[optional.optional.ref.general]{General}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we call this [optional.ref.general] instead? It's a sibling of [optional.ref.ctor], [optional.ref.assign], etc.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good call. What about [optional.optional.ref], though?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same.

[optional.optional.ref*] is just stupid; we spent plenty of effort to get rid of [stmt.stmt].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could change that too, but my main concern was the excessive length of optional.optional.ref.general

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, good point that we shouldn't immediately create a new set of problematic names that will invite ridicule and disbelief.

Can we come up with an acceptable complete set of new labels for this paper?

Copy link
Contributor Author

@steve-downey steve-downey Jun 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The challenge is the parallelism with the existing mess that has [optional.optional.general] and then the ctors in [optional.ctor]. I had optionalref instead of optional.ref at one point, but that is not better.

 \rSec1[optional]{Optional objects}
 \rSec2[optional.general]{General}
 \rSec2[optional.syn]{Header \tcode{<optional>} synopsis}
 \rSec2[optional.optional]{Class template \tcode{optional}}
 \rSec3[optional.optional.general]{General}
 \rSec3[optional.ctor]{Constructors}
 \rSec3[optional.dtor]{Destructor}
 \rSec3[optional.assign]{Assignment}
 \rSec3[optional.swap]{Swap}
 \rSec3[optional.iterators]{Iterator support}
 \rSec3[optional.observe]{Observers}
 \rSec3[optional.monadic]{Monadic operations}
 \rSec3[optional.mod]{Modifiers}
+\rSec2[optional.optional.ref]{Partial specialization of \tcode{optional} for reference types}
+\rSec3[optional.optional.ref.general]{General}
+\rSec3[optional.ref.ctor]{Constructors}
+\rSec3[optional.ref.assign]{Assignment}
+\rSec3[optional.ref.swap]{Swap}
+\rSec3[optional.ref.iterators]{Iterator support}
+\rSec3[optional.ref.observe]{Observers}
+\rSec3[optional.ref.monadic]{Monadic operations}
+\rSec3[optional.ref.mod]{Modifiers}
+\rSec3[optional.ref.expos]{Exposition only helper functions}
 \rSec2[optional.nullopt]{No-value state indicator}
 \rSec2[optional.bad.access]{Class \tcode{bad_optional_access}}
 \rSec2[optional.relops]{Relational operators}

Possibly changing the [optional.optional.ref] ones to [optional.ref] would be least worst?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly changing the [optional.optional.ref] ones to [optional.ref] would be least worst?

Good enough for me

Comment on lines +4908 to +4912
if (has_value()) {
return invoke(std::forward<F>(f), *@\exposid{val}@);
} else {
return remove_cvref_t<U>();
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC LWG didn't want these braces here, but it's consistent with the equivalent functions for optional<T>. We can remove them from both places later if necessary.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, surely this is editorial? Why is LWG opposed to braces? Have braces ever decreased clarity of presentation? goto fail; goto fail.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes definitely editorial. It's just shorter without the braces (only by one line, admittedly).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[2025-06 LWG Motion 2] P2988R12 std::optional<‍T&‍> P2988 R12 std::optional<T&>
4 participants