Proposed resolution:

This wording is relative to N4835.

1. Modify [allocator.requirements], Table [tab:cpp17.allocator] "Cpp17Allocator requirements" as indicated:

   Table 34 — Cpp17Allocator requirements [tab:cpp17.allocator]

   Expression	Return type	Assertion/note pre-/post-condition	Default
   …
   a.construct(c, args)	(not used)	Effects: Constructs an object of type C at c	::new ((void*)c) C(construct_at(c, std::forward<Args>(args)...)
   a.destroy(c)	(not used)	Effects: Destroys the object at c	c->~C()destroy_at(c)
   …

[ 2019-11 Status to Ready during Wednesday morning issue processing in Belfast. ]

Addresses US 162/US 163

US 162:

The default behavior for a.destroy is now to call destroy_at

Proposed change:

Replace "default" entry with: destroy_at(c)

US 163:

The default behavior for a.construct is now to call construct_at

Proposed change:

Replace "default" entry with: construct_at(c, std::forward<Args>(args)...)

Dietmar Kühl:

In Table 34 [tab:cpp17.allocator] the behavior of a.construct(c, args) and a.destroy(c) are described to have a default behavior of ::new ((void*)c) C(forward<Args>(args)) and c->~C(), respectively. However, this table doesn't actually define what is happening if these operations are omitted: The behavior is provided when using an allocator is used via std::allocator_traits and is, thus, defined by the corresponding std::allocator_traits functions. These functions are specified in [allocator.traits.members] paragraphs 5 and 6 to call construct_at(c, std::forward<Args>(args) and destroy_at(p), respectively. The text in the table should be updated to match the actual behavior.