This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.
Section: 16.4.5.2.1 [namespace.std], 17.10 [support.initlist] Status: C++17 Submitter: Richard Smith Opened: 2012-01-18 Last modified: 2017-07-30
Priority: 3
View all other issues in [namespace.std].
View all issues with C++17 status.
Discussion:
Since the implementation is intended to magically synthesize instances of std::initializer_list (rather than by a constructor call, for instance), user specializations of this type can't generally be made to work. I can't find any wording which makes such specializations ill-formed, though, which leads me to suspect that they're technically legal under the provisions of 16.4.5.2.1 [namespace.std] p1.
[2012, Kona]
This sounds correct, but we need wording for a resolution.
Marshall Clow volunteers to produce wording.
[2014-02-19, Jonathan Wakely provides proposed wording]
[2014-03-27, Library reflector vote]
The issue has been identified as Tentatively Ready based on six votes in favour.
Proposed resolution:
This wording is relative to N3936.
Add new new paragraph below 17.10 [support.initlist] p2:
-2- An object of type initializer_list<E> provides access to an array of objects of type const E. […]
-?- If an explicit specialization or partial specialization of initializer_list is declared, the program is ill-formed.