On 5 October 2017 at 15:08, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On 6 October 2017 at 01:04, Richard Smith <richard_at_[hidden]> wrote:
> >> 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();
> >
> >
> > The macro does not help you with that. It does not magically make a C++17
> > feature appear in C++14 mode.
>
> I can avoid compiling that when I know it won't work, for which I can
> use the macro. I can compile that when I know
> it'll work, for which the macro tells me that it'll work.
>

The thing I'm missing is what alternative you use when the feature is not
available, and why you would not use that alternative in all cases if you
want your code to be portable across compilers. Your original example is
not that, because you can just use the version with
__cpp_guaranteed_copy_elision
not defined, with no loss of functionality.

>> 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.
> >
> >
> > I think we're still missing an example of that.
>
> That would be wrapping the whole type in #ifdef
> __cpp_mandatory_copy_elision, and providing
> a different type that doesn't rely on copy elision, like a type that
> is movable and has a different name.


 This sounds promising. Can you give an example?