760. The emplace issue

Section: 23.2 [container.requirements] Status: NAD Submitter: Paolo Carlini Opened: 2007-11-11 Last modified: 2017-07-17

Priority: 2

View all other issues in [container.requirements].

View all issues with NAD status.

Discussion:

In an emplace member function the function parameter pack may be bound to a priori unlimited number of objects: some or all of them can be elements of the container itself. Apparently, in order to conform to the blanket statement 23.2 [container.requirements]/11, the implementation must check all of them for that possibility. A possible solution can involve extending the exception in 23.2 [container.requirements]/12 also to the emplace member. As a side note, the push_back and push_front member functions are luckily not affected by this problem, can be efficiently implemented anyway.

[ Related to 767 and to 2164 ]

[ Bellevue: ]

The proposed addition (13) is partially redundant with the existing paragraph 12. Why was the qualifier "rvalues" added to paragraph 12? Why does it not cover subelements and pointers?

Resolution: Alan Talbot to rework language, then set state to Review.

[ 2009-07 Frankfurt ]

The problem is broader than emplace. The LWG doesn't feel that it knows how to write wording that prohibits all of the problematic use cases at this time.

NAD Future.

[2015-02 Cologne]

LWG believes that 2164 addresses this issue and therefore considers 760 as NAD.

Proposed resolution:

Add after 23.2 [container.requirements]/12:

-12- Objects passed to member functions of a container as rvalue references shall not be elements of that container. No diagnostic required.

-13- Objects bound to the function parameter pack of the emplace member function shall not be elements or sub-objects of elements of the container. No diagnostic required.