This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Concepts status.

### 1074. concept map broken by N2840

Section: 99 [allocator.element.concepts] Status: NAD Concepts Submitter: Alisdair Meredith Opened: 2009-03-19 Last modified: 2016-01-28

Priority: Not Prioritized

View all issues with NAD Concepts status.

Discussion:

p7 Allocator-related element concepts 99 [allocator.element.concepts]

The changes to the `AllocatableElement` concept mean this `concept_map` specialization no longer matches the original concept:

>     template <Allocator Alloc, class T, class ... Args>
>       requires HasConstructor<T, Args...>
>         concept_map AllocatableElement<Alloc, T, Args&&...> {
>           void construct_element(Alloc& a, T* t, Args&&... args) {
>             Alloc::rebind<T>(a).construct(t, forward(args)...);
>           }
>         }

[ 2009-03-23 Pablo adds: ]

> Actually, this is incorrect, N2840 says. "In section 99 [allocator.element.concepts] paragraph 8, modify the definition of the `AllocatableElement` concept and eliminate the related concept map:" but then neglects to include the red-lined text of the concept map that was to be eliminated. Pete also missed this, but I caught it he asked me to review his edits. Pete's updated WP removes the concept map entirely, which was the original intent. The issue is, therefore, moot. Note, as per my presentation of N2840 in summit, `construct()` no longer has a default implementation. This regrettable fact was deemed (by David Abrahams, Doug, and myself) to be preferable to the complexity of providing a default implementation that would not under-constrain a more restrictive allocator (like the scoped allocators).

[ 2009-05-01 Daniel adds: ]

> it seems to me that #1074 should be resolved as a NAD, because the current WP has already removed the previous AllocatableElement concept map. It introduced auto concept AllocatableElement instead, but as of 99 [allocator.element.concepts]/7 this guy contains now

> >     requires FreeStoreAllocatable<T>;
> >     void Alloc::construct(T*, Args&&...);

[ Batavia (2009-05): ]

> The affected code is no longer part of the Working Draft.

> Move to NAD.

Proposed resolution:

Change 99 [allocator.element.concepts]:

>     template <Allocator Alloc, class T, class ... Args>
>       requires HasConstructor<T, Args...>
>         concept_map AllocatableElement<Alloc, T, Args&&...> {
>           void construct_element(Alloc& a, T* t, Args&&... args) {
>             Alloc::rebind<T>(a).construct(t, forward(args)...);
>           }
>         }