Title
The `std::make_optional` overload taking `std::initializer_list` should not accept a reference type as its template argument
Status
new
Section
[optional.specalg]
Submitter
Jiang An

Created on 2025-12-25.00:00:00 last changed 4 days ago

Messages

Date: 2026-01-17.15:20:29

Proposed resolution:

This wording is relative to N5032.

  1. Modify [optional.specalg] as indicated:

    [Drafting note: This also make the implicit SFINAE constraints introduced by [structure.specifications] p4 explicit.]

    template<class T, class U, class... Args>
      constexpr optional<T> make_optional(initializer_list<U> il, Args&&... args);
    

    -?- Constraints: is_lvalue_reference_v<T> is `false` and is_constructible_v<T, initializer_list<U>&, Args...> is `true`.

    -6- Effects: Equivalent to: return optional<T>(in_place, il, std::forward<Args>(args)...);

Date: 2025-12-25.00:00:00

std::make_optional<std::initializer_list<int>&>({1, 2}) is currently valid, but the returned `optional` object contains a dangling reference, because the stored reference used to refer to the initializer_list<int> parameter object of that `make_optional` overload.

Moreover, when there's already an initializer_list<T> variable `il`, std::make_optional<std::initializer_list<T>&>(il) also returns an `optional` containing a dangling reference, because the third `make_optional` overload in [optional.specalg] is more specialized than the second and thus gets selected.

Given optional<T&> has no specific initializer-list constructor, perhaps we should make the `make_optional` overload taking `initializer_list` not accept T& as its first template argument.

History
Date User Action Args
2026-01-17 15:20:29adminsetmessages: + msg15882
2025-12-25 00:00:00admincreate