Skip to content

LWG2432 initializer_list assignability #1369

Description

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

Activity

  1. added this to the 2023-telecon milestone on Jan 25, 2023
  2. jfbastien commented on Jun 12, 2023

    @jfbastien
    CollaboratorAuthor

    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;
    
  3. erichkeane commented on Jun 12, 2023

    @erichkeane
    Collaborator

    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.

  4. jwakely commented on Nov 13, 2023

    @jwakely
    Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    LWGLibrary

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions