> std::elide is a single library feature which not only works with std::optional, std::vector, std::deque, std::list, et cetera but also with innumerable classes, utilities, et cetera provided by user libraries. We standardize this and we get interoperation with all of those.

But we established that it doesn't work, hence the core language exception.


> Going the route of adding a new basis operation requires us to modify all the containers (and non-containers too, you'd need a function-invoking version of std::make_shared and std::make_unique as well) and to have that pattern percolate through the entire user ecosystem just to get what can be transparently enabled with a single library utility.

Adding a couple of extra methods to existing containers is not a big deal. I think you are exaggerating the amount of work required.
And I don't find the argument that we are too lazy to do it compelling given the alternative.


> Your rationale for opposing std::elide seems to be a fixation on the idea that emplacement should exclusively call constructors.

No, my objection is that the function call does not occur explicitly as it should, and instead of implementing a proper solution we are setting for this hack. Which doesn't work properly because its a function call disguised as an object. And the reason for that is because we are too lazy...