sob., 12 sie 2023 o 19:26 Thiago Macieira <thiago_at_[hidden]> napisał(a):
>
> On Saturday, 12 August 2023 09:14:28 PDT Marcin Jaczewski wrote:
> > What is the point of any keyword or anything else there?
> > why code like:
> > ```
> > Mutex m;
> > return m;
> > ```
> > could not work out of the box?
>
> I don't know, I didn't investigate the situation. I assumed that there was a
> reason, but you're showing that that assumption is incorrect.
>
> > ```
> > {
> > int [[nrvo]] i = 0;
> >
> > if (x) return 0; //compiler error, `i` was defined `nrvo` but
> > // diffrent object was returned during life time of `i`
> >
> > return i;
> > }
>
> This can't be an error with just a plain attribute. It can be a warning, which
> in turn must mean the code is perfectly legal otherwise.
>
> Or if it is a syntactic error (let's please stop using "int" because it is
> neither unmovable nor does it have a return slot), then the attribute is
> unnecessary.

Only the lack of a return slot is a problem for this example.
Fact is the movable type is exactly the answer to Jason concerns he mentions
in his email. If a user wants to rely on NRVO (like a stable address) is
prefered to opt-in into this behavior, in this case its not exactly opt-in
is more "I expect that I have there NRVO".
Compiler error is required in this case as otherwise we would
have "miss compiled" code and different behavior than the user expected.

Beside compilation error is less severe than UB that other attributes
can cause if a user puts them on the wrong thing.
No correct program will be affected, but incorrect will be.

To sum up, this example will simply have error in different place,
istead on this middle return it will be on line `int [[nrvo]] i = 0;` with
message "trivial type `int` does not support NRVO".

>
> It would only be useful where NVRO is an optional optimisation and you want
> the compiler to warn you if it couldn't be applied. By extension, the
> attribute could be applied where the named return is mandatory, but that being
> the case, there would never be a warning.
>

I would not consider this an optimization, more a rule when objects in
return slot are created.

> > Attribute is here only to state intention and prevent errors
> > (like the user wanted NRVO but the compiler could not provide it).
> > This should be general rule in lange, identity of returned object
> > should be always preserved (if returning thing is of course unabigius).
>
> Agreed.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel DCAI Cloud Engineering
>
>
>