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)...);

[ 2026-02-18; Reflector poll. ]

Set priority to 4 after reflector poll.

This only affects edge cases like make_optional<initializer_list<int>&>({....}). The is_constructible_v constraint seems unmotivated by the issue.

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.