Title
User specializations of std::initializer_list
Status
c++17
Section
[namespace.std] [support.initlist]
Submitter
Richard Smith

Created on 2012-01-18.00:00:00 last changed 90 months ago

Messages

Date: 2015-09-23.18:37:53

Proposed resolution:

This wording is relative to N3936.

  1. Add new new paragraph below [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.

Date: 2014-03-15.00:00:00

[ 2014-03-27, Library reflector vote ]

The issue has been identified as Tentatively Ready based on six votes in favour.

Date: 2014-02-15.00:00:00

[ 2014-02-19, Jonathan Wakely provides proposed wording ]

Date: 2015-09-23.18:37:53

[ 2012, Kona ]

This sounds correct, but we need wording for a resolution.

Marshall Clow volunteers to produce wording.

Date: 2012-01-18.00:00:00

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 [namespace.std] p1.

History
Date User Action Args
2017-07-30 20:15:43adminsetstatus: wp -> c++17
2015-09-23 18:37:53adminsetmessages: + msg7534
2015-09-23 18:37:53adminsetmessages: + msg7533
2015-09-23 18:37:53adminsetmessages: + msg7532
2014-11-08 19:44:42adminsetstatus: voting -> wp
2014-11-04 10:26:50adminsetstatus: ready -> voting
2014-03-27 19:50:36adminsetstatus: open -> ready
2014-03-24 21:32:13adminsetmessages: + msg6909
2012-02-12 18:36:43adminsetstatus: new -> open
2012-01-18 00:00:00admincreate