>From the perspective of polymorphic allocators, I don't think the issue really applies. Since a polymorphic allocator is a completely separate thing from the memory resources it can be using, there really is no difference in copying vs moving the allocator that I can see. The underlying memory resource is not affected by how the allocator reference types that refer to it are handled.

Phrased differently, depending on implementation it's the underlying memory resource that may have copy / move restrictions in place (imagine accidentally copying a shared memory segment for instance).

There are likely a large amount of pre-C++17 allocators in use that don't have the allocator / resource split, and are thus "broken" for some value of "broken".
>From: Martin Sjogren <msjogren_at_[hidden]>
>
>Exactly my point. If they need a functioning allocator in their moved-from state, shouldn't they be copying the allocator instead of moving it, rather than imposing a (in my opinion) counter-intuitive requirement on allocators?
>
>On Mon, Jun 3, 2019 at 10:38 PM Tony V E <tvaneerd_at_[hidden]> wrote:
>
>>
>>
>> On Mon, Jun 3, 2019 at 10:52 AM Martin Sjogren via Std-Discussion <
>> std-discussion_at_[hidden]> wrote:
>>
>>> As a result of https://cplusplus.github.io/LWG/issue2593 after
>>> move-constructing an allocator x from an allocator y the standard
>>> will require that x and y compare equal. My understanding is that
>>> this is because moving a container also moves the allocator, but
>>> (some?) moved-from containers still need a functioning allocator.
>>>
>>> But doesn't this effectively mean that moving from an allocator is
>>> impossible and in the vast majority of cases moving needs to be
>>> implemented as copying?
>>>
>>> Wouldn't it make more sense for the containers that need an allocator
>>> in their moved-from state to copy their allocator instead of moving?
>>>
>>
>> All standard containers that have an allocator need an allocator in
>> their moved-from state. A moved-from container is still a functioning container.
>>
>>
>>> As-is, I feel like there's a big trap when implementing an allocator
>>> that you have to take very special care with the move constructor (or
>>> in practice just not have one)
>>>
>>> Would there be any interest in an issue report for this?

________________________________

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.