std::initializer_list
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 other active issues in [namespace.std].
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
-?- If an explicit specialization or partial specialization ofinitializer_list<E>
provides access to an array of objects of typeconst E
. […]initializer_list
is declared, the program is ill-formed.