> > And as far as exception safety is concerned, I'm not in the slightest bothered by it given that if an exception is thrown the unwinder must be competent enough to understand the context it has been thrown in and call the appropriate routine to clean it up.
> I'm not sure how that would work in general, as that context can be entirely opaque to the std::factory call itself. It needs to be specified in what state should the passed in `setup` function should leave the object if it exits by exception.

The "setup function" doesn't care, what it gets is a reference to an object that is being managed somewhere else (namely in the internals of std::factory), as far is it concerned it is just like any other function that takes in parameters by reference. If the object has thrown prior to the call to the "setup" than the setup wouldn't be called as std::factory would be unwinding before it gets there. std::factory itself if the setup has thrown and the object is already constructed it must now call the destructor to destroy the object as it is being unwound. This would be true of std::factory or any other function that NRVOs, for reasons that should be quite obvious (and if they are not, I can explain them).

And I think that is all that needs to be said about exceptions, unless there's something I'm missing.