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.

2129. User specializations of 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.

1. 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.