Title
Inconsistent specifications for std::make_optional overloads
Status
wp
Section
[optional.specalg]
Submitter
Jiang An

Created on 2021-10-23.00:00:00 last changed 5 days ago

Messages

Date: 2025-11-11.10:48:16

Proposed resolution:

This wording is relative to N4901.

  1. Modify [optional.specalg] as indicated:

    template<class T> constexpr optional<decay_t<T>> make_optional(T&& v);
    

    -3- ReturnsEffects: Equivalent to: return optional<decay_t<T>>(std::forward<T>(v));.

Date: 2025-11-11.10:48:16

[ Kona 2025-11-08; Status changed: Voting → WP. ]

Date: 2025-10-15.00:00:00

[ 2025-10-16; Status changed: New → Tentatively Ready. ]

Reflector poll in 2024-07 with eight supporting votes.

Date: 2022-01-15.00:00:00

[ 2022-01-29; Reflector poll ]

Set priority to 3 after reflector poll.

Date: 2021-10-23.00:00:00

Three std::make_optional overloads are specified in [optional.specalg]. The first one is specified by "Returns:" and the other two are specified by "Effects: Equivalent to:". According to [structure.specifications]/4, such uses of "Effects: Equivalent to:" propagate the Constraints specified for constructors. As the selected constructor for the first overload has "Constraints:" ([optional.ctor]/22), it seems that inconsistency is introduced here.

Existing implementations are inconsistent: libstdc++ constrains all three overloads, while libc++ and MSVC STL do not constrain any of them.

IMO all three overloads should be constrained.

History
Date User Action Args
2025-11-11 10:48:16adminsetmessages: + msg15613
2025-11-11 10:48:16adminsetstatus: voting -> wp
2025-10-30 17:45:31adminsetstatus: ready -> voting
2025-10-16 11:35:46adminsetmessages: + msg15178
2025-10-16 11:35:46adminsetstatus: new -> ready
2022-01-29 22:29:35adminsetmessages: + msg12295
2021-10-24 18:01:32adminsetmessages: + msg12199
2021-10-23 00:00:00admincreate