Date: Tue, 7 Jul 2026 20:10:05 -0700
Hello,
Now that P2988R12 containing std::optional<T&> has been recommended by the
Library Working Group, I thought I would suggest adding the same monadic
overrides std::optional<T> has (and std::optional<T&> is proposed to have)
to std::unique_ptr, std::shared_ptr and std::weak_ptr.
To my eye std::optional<&T> is a non-owning pointer. If we are going to add
a non-owning pointer class with helper functions "for safety" then it would
make sense to me to have the owning pointer classes try to be at least as
safe. This would involve adding and_then, or_else, value_of and transform.
It might make sense to limit std::unique_ptr::or_else such that it is only
callable on a temporary or in some other manner so that it doesn't result
in the owned object being accidentally deleted.
I would also like to personally object to adding std::optional<&T> and
suggest calling the same construct std::optref<T> (or std::optional_ref<T>)
because it is confusing that, as C++ references go, std::optional<&T>
doesn't walk like a duck. Although, the use cases illustrated in P2988R12
are compelling.
Regards,
Adrian
Now that P2988R12 containing std::optional<T&> has been recommended by the
Library Working Group, I thought I would suggest adding the same monadic
overrides std::optional<T> has (and std::optional<T&> is proposed to have)
to std::unique_ptr, std::shared_ptr and std::weak_ptr.
To my eye std::optional<&T> is a non-owning pointer. If we are going to add
a non-owning pointer class with helper functions "for safety" then it would
make sense to me to have the owning pointer classes try to be at least as
safe. This would involve adding and_then, or_else, value_of and transform.
It might make sense to limit std::unique_ptr::or_else such that it is only
callable on a temporary or in some other manner so that it doesn't result
in the owned object being accidentally deleted.
I would also like to personally object to adding std::optional<&T> and
suggest calling the same construct std::optref<T> (or std::optional_ref<T>)
because it is confusing that, as C++ references go, std::optional<&T>
doesn't walk like a duck. Although, the use cases illustrated in P2988R12
are compelling.
Regards,
Adrian
Received on 2026-07-08 03:10:32
