On Mon, May 27, 2024 at 11:51 PM Tiago Freire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> What you are doing is way too complicated for what is actually required.
>
 [...]

> And the condition that seems to best maximize this is, "copy elision of a
> named variable is guaranteed if its lifetime does not overlap in any scope
> with another object that could also possibly be returned".
>
> It is a simple sentence to change in the core language, it allows you to
> do everything you want in all circumstances that are possible, you don't
> need to write code differently, it doesn't do anything that the compiler
> isn't already allowed to do (but decides not to), you don't need to add a
> new library features or functions or keywords or hoops to jump, no gotchas,
> you can't do it wrong, you are able to express intent in a coherent manner
> and allow the compiler to do its job,
> It always works and everything benefits regardless of it being
> immovable/uncopiable or otherwise. That's it, you don't need anything else.
>

I agree with you on the part that volatile opcode arrays that you can jump
into are no-go for standardisation (it's nice for a prototype, but that's
different from standardisation). I also agree that the sentence you write
above solves the NRVO issue. However, before I wrote (and the reason why I
wrote) the @-notation is that there were additional issues mentioned on the
list. This includes returning char arrays and similar. Now, you might say
that *it can be solved as* a separate issue, but *there's a solution* that
solves *both*. Besides these, we agree I think.

Thanks,
-lorro