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.