Subject: Re: [SG10] A feature macro for mandatory copy elision
From: Richard Smith (richard_at_[hidden])
Date: 2017-10-05 17:04:05
On 5 Oct 2017 14:54, "Ville Voutilainen" <ville.voutilainen_at_[hidden]>
On 6 October 2017 at 00:48, Richard Smith <richard_at_[hidden]> wrote:
> On 5 Oct 2017 14:20, "Ville Voutilainen" <ville.voutilainen_at_[hidden]>
> On 5 October 2017 at 23:50, Richard Smith <richard_at_[hidden]> 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();
The macro does not help you with that. It does not magically make a C++17
feature appear in C++14 mode.
> 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
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
I think we're still missing an example of that.
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.
SG10 list run by firstname.lastname@example.org