LWG2432 initializer_list assignability

[jfbastien]

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:

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:

namespace std {
  template<class E> class initializer_list {
  public:
    […]
    constexpr initializer_list() noexcept;
  
    initializer_list(const initializer_list&) = default;
    initializer_list(initializer_list&&) = default;
    initializer_list& operator=(const initializer_list&) = delete;
    initializer_list& operator=(initializer_list&&) = delete;
    
    constexpr size_t size() const noexcept;
    […]
  };
  […]
}

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

Meeting: Proposed resolution:

initializer_list(const initializer_list&) = default;
initializer_list(initializer_list&&) = default;
[[deprecated]] initializer_list& operator=(const initializer_list&) = default;
[[deprecated]] initializer_list& operator=(initializer_list&&) = default;

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.

[jfbastien]

Tim Song points out new info:

It occurred to me yesterday that we can now do what [LWG2432] wanted with something like

      initializer_list& operator=(convertible_to<initializer_list> auto&& __rhs) { /* ... */ }
      initializer_list& operator=(initializer_list const&) requires false = default;

[erichkeane]

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.

[jwakely]

LWG revisited this in Kona and the direction from EWG has been added to the issue.