czw., 11 lip 2024 o 23:15 Thiago Macieira via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Thursday 11 July 2024 13:33:54 GMT-7 Tiago Freire wrote:
> > I agree with having a gadget to be able to tell you "when it cannot do it".
> > But that's a different thing from having a gadget that tells it that "it
> > must do it" or "to what to do it too". Warning that it didn't do it when
> > you expect it too. Is a different thing from adding a rule as to when it
> > must do it. The doing it part should require no annotation. You can have an
> > annotation to tell you if it did.
>
> Agreed, I don't think we need to change the rules of when it can do it. There
> may be some future need to allow NRVO where today it isn't possible, but I
> can't think of one right now. Therefore, all cases where it can implement NRVO
> are already implemented.
>
> We need the syntax to enforce it.
>

Deleting copy and move constructors? If NRVO is not possible then
code will not compile. You can even do this today by adding
fake copy constructor that has no definition. It will fall during linking.

Question is case for movable type that need keed object identity during return?
Probably trying using types like this that allow copy and move but still
need to hold the same identity will be fragile as you can move data
from a given object right after function return.

> But we also need to have the rules written down, so code can depend on it, if
> we want to have a standard attribute. Either that or we make the rule
> implementation-defined behaviour that must be documented and we get the ABI-
> compatible implementations to agree on them.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals