On 6 October 2017 at 00:48, Richard Smith <rich...@metafoo.co.uk> wrote: > On 5 Oct 2017 14:20, "Ville Voutilainen" <ville.voutilai...@gmail.com> > wrote: > > On 5 October 2017 at 23:50, Richard Smith <rich...@metafoo.co.uk> wrote: >> What benefit does the feature-test macro give you over using the >> non-guaranteed-copy-elision implementation in all cases? > > I can let users store the thing returned by the factory function as > they would store any object, > rather than force them to use lifetime-extending references. > > > One of us is missing something. Why does that not work with > the non-guaranteed-copy-elision implementation?
I can't write NoCopyNorMove x = factory(); in C++14. It's ill-formed. Same goes for auto x = factory(); > > Furthermore, if I decide that I really > hate having to use those references, I will disable the whole type if > guaranteed copy elision is not available. > > > Do you anticipate actually wanting to do that? It seems like an odd choice > to permit the reference declaration only if guaranteed copy elision is > available. The choice is that rather than performing tricks with having to befriend every possible factory function and forcing users to use lifetime-extending references, such RAII handles are provided only when copy elision is available, and otherwise completely different tools need to be used. This discussion generalizes to the following: mandatory copy elision allows doing things that were not doable before. That provides ample reason to have a feature macro for it, as far as I'm concerned. _______________________________________________ Features mailing list Features@isocpp.open-std.org http://www.open-std.org/mailman/listinfo/features
