Date: Sun, 10 Mar 2024 18:40:11 +0100
On 10/03/2024 17.24, Frederick Virchanza Gotham via Std-Proposals wrote:
>
>
> On Sunday, March 10, 2024, Jens Maurer wrote:
>
>
> The standard owns std::optional and std::variant, so asking the
> standard library to cooperate with another standard library
> component seems the most straightforward approach. Same for
> third-party components, if they so desire.
>
>
>
> Okay you have me here: If we're going to add 'elide_t' to the standard library then why not just add a method called 'emplace_invoke' to optional, variant, any, vector, etc. -- which would do away with the need for 'elide_t'.
Yes.
> What's wrong with var.emplace(std::allocator<int>()) ?
> This won't move a MonkeyAllocator around, I believe.
>
>
>
> Le's say that MonkeyAllocator is a library function and you don't know what happens inside it (maybe it has side effects that are only apparent within the library). Also let's say that the allocator itself contains an atomic flag and is therefore unmovable.
There's only one MonkeyAllocator created by that .emplace invocation: the one at
the final resting place. Also, std::allocator is copyable, so can't contain funny
types, as is any other standard-conforming allocator. See [allocator.requirements.general] .
Jens
>
>
> On Sunday, March 10, 2024, Jens Maurer wrote:
>
>
> The standard owns std::optional and std::variant, so asking the
> standard library to cooperate with another standard library
> component seems the most straightforward approach. Same for
> third-party components, if they so desire.
>
>
>
> Okay you have me here: If we're going to add 'elide_t' to the standard library then why not just add a method called 'emplace_invoke' to optional, variant, any, vector, etc. -- which would do away with the need for 'elide_t'.
Yes.
> What's wrong with var.emplace(std::allocator<int>()) ?
> This won't move a MonkeyAllocator around, I believe.
>
>
>
> Le's say that MonkeyAllocator is a library function and you don't know what happens inside it (maybe it has side effects that are only apparent within the library). Also let's say that the allocator itself contains an atomic flag and is therefore unmovable.
There's only one MonkeyAllocator created by that .emplace invocation: the one at
the final resting place. Also, std::allocator is copyable, so can't contain funny
types, as is any other standard-conforming allocator. See [allocator.requirements.general] .
Jens
Received on 2024-03-10 17:40:16