Proposed resolution:

Replace "new" with "::new" in:

• [uninitialized.copy], paragraphs 1 and 3
• [uninitialized.fill] paragraph 1
• [uninitialized.fill.n] paragraph 1
• [util.smartptr.shared.create] once in paragraph 1 and twice in paragraph 2.

[ post San Francisco: ]

Daniel: HasPlacementNew has been removed from N2774 (Foundational Concepts).

[ San Francisco: ]

Detlef: If we move this to Ready, it's likely that we'll forget about the side comment about the HasPlacementNew concept.

LWG issue 402 replaced "new" with "::new" in the placement new-expression in [allocator.members]. I believe the rationale given in 402 applies also to the following other contexts:

• in [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 [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.