You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
std::initializer_list::operator= 17.11 [support.initlist] is horribly broken and it needs deprecation:
std::initializer_list<foo> a = {{1}, {2}, {3}};
a = {{4}, {5}, {6}};
// New sequence is already destroyed.
Assignability of initializer_list isn't explicitly specified, but most implementations supply a default assignment operator. I'm not sure what 16.3 [description] says, but it probably doesn't matter.
[Lenexa 2015-05-05: Send to EWG as discussed in Telecon]
[2022-08-24; Reflector poll]
Set status to Tentatively NAD after reflector poll in October 2021.
"If somebody wants to revisit it, they'll need to write a paper to demonstrate what the change would break, whether that would be a problem in practice, and convince the evolution groups to make a change. But it's not an LWG issue."
Proposed resolution:
Edit 17.11 [support.initlist]p1, class template initializer_list synopsis, as indicated:
LWG telecon appears to want a language change to disallow assigning a braced-init-list to an std::initializer_list but still permit move assignment of std::initializer_list objects. That is,
auto il1 = {1,2,3};
auto il2 = {4,5,6};
il1 = {7,8,9}; // currently well-formed but dangles immediately; should be ill-formed
il1 = std::move(il2); // currently well-formed and should remain so
EWG Discussed this on Monday in Varna, and the following poll was taken:
Send LWG2432 back to LWG to encourage them to either add a note for their implementer to issue a warning as QoI, or to use the tools (explicit convertible_to operator=) at their disposal to accomplish their goal.
SF
F
N
A
SA
1
10
6
0
1
Result: Consensus
Sending back to LWG to use either Tim's trick, or ask for a 'dangling reference' diagnostic from their implementers as QoI.
Migrating from https://isocpp.org/files/papers/P1018R18.html#issues
https://cplusplus.github.io/LWG/issue2432
Section: 17.11 [support.initlist] Status: Tentatively NAD Submitter: David Krauss Opened: 2014-09-30 Last modified: 2022-09-03
Priority: 2
View other active issues in [support.initlist].
View all other issues in [support.initlist].
View all issues with Tentatively NAD status.
Discussion:
std::initializer_list::operator= 17.11 [support.initlist] is horribly broken and it needs deprecation:
Assignability of initializer_list isn't explicitly specified, but most implementations supply a default assignment operator. I'm not sure what 16.3 [description] says, but it probably doesn't matter.
[Lenexa 2015-05-05: Send to EWG as discussed in Telecon]
[2022-08-24; Reflector poll]
Set status to Tentatively NAD after reflector poll in October 2021.
"If somebody wants to revisit it, they'll need to write a paper to demonstrate what the change would break, whether that would be a problem in practice, and convince the evolution groups to make a change. But it's not an LWG issue."
Proposed resolution:
Edit 17.11 [support.initlist] p1, class template initializer_list synopsis, as indicated:
LWG telecon appears to want a language change to disallow assigning a braced-init-list to an std::initializer_list but still permit move assignment of std::initializer_list objects. That is,
Meeting: Proposed resolution:
SF F N A SA
0 3 12 0 0
JF emailed LEWG, to see if they have an opinion, no feedback. Asked LEWG chairs to schedule for a telecon.
LWG discussed priority.
The text was updated successfully, but these errors were encountered: