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'.

So I suppose my only remaining argument would be for classes outside the
standard library that don't yet have 'emplace_invoke' -- unless there's a
compelling reason why we only want to have 'emplace'. Perhaps if we only
have 'emplace', combined with 'elide_t', it would mean that many pieces of
pre-existing 3rd party code would not have to be edited. This might be a
big benefit. What I'm saying is that if there are thousands and thousands
of lines of code written which use 'emplace' then, after adding 'elide_t'
to the standard, we can simply hit recompile without having to edit the
code.



std::piecewise_construct is entirely a library facility.




I didn't realise that a constructor had been added to std::pair which takes
an std::piecewise_construct . . . I thought there was some sort of magic
going on but now I can see that it's achievable without a core language
change l.



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.