This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 27.11 [specialized.algorithms], 20.3.2.2.7 [util.smartptr.shared.create] Status: C++11 Submitter: Alberto Ganesh Barbati Opened: 2008-07-14 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [specialized.algorithms].
View all other issues in [specialized.algorithms].
View all issues with C++11 status.
Discussion:
LWG issue 402 replaced "new" with "::new" in the placement new-expression in 20.2.10.2 [allocator.members]. I believe the rationale given in 402 applies also to the following other contexts:
in 27.11 [specialized.algorithms], all four algorithms unitialized_copy, unitialized_copy_n, unitialized_fill and unitialized_fill_n use the unqualified placement new-expression in some variation of the form:
new (static_cast<void*>(&*result)) typename iterator_traits<ForwardIterator>::value_type(*first);
in 20.3.2.2.7 [util.smartptr.shared.create] there is a reference to the unqualified placement new-expression:
new (pv) T(std::forward<Args>(args)...),
I suggest to add qualification in all those places. As far as I know, these are all the remaining places in the whole library that explicitly use a placement new-expression. Should other uses come out, they should be qualified as well.
As an aside, a qualified placement new-expression does not need additional requirements to be compiled in a constrained context. By adding qualification, the HasPlacementNew concept introduced recently in N2677 (Foundational Concepts) would no longer be needed by library and should therefore be removed.
[ San Francisco: ]
Detlef: If we move this to Ready, it's likely that we'll forget about the side comment about the HasPlacementNew concept.
[ post San Francisco: ]
Daniel: HasPlacementNew has been removed from N2774 (Foundational Concepts).
Proposed resolution:
Replace "new" with "::new" in: