On 5 October 2017 at 15:08, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On 6 October 2017 at 01:04, Richard Smith <richard@metafoo.co.uk> 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?