On Thu, Mar 18, 2021 at 3:34 PM Omer Rosler via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Thanks for the detailed response.
> Here is my response:
>
>> This is very similar to `restrict`/`noalias`, and has the same issues (plus a few more issues that I think are easily severed).
>> https://www.lysator.liu.se/c/dmr-on-noalias.html
>
>
> Didn't know about `noalias` and reading this (was an interesting read), it is very similar.
>
> Quoting the article:
>>
>> The utter wrongness of `noalias' is that the information it seeks to convey is not a property of an object at all. `Const,' for all its technical faults, is at least a genuine property of objects; `noalias' is not, and the committee's confused attempt to improve optimization by pinning a new qualifier on objects spoils the language. `Noalias' is a bogus invention that is not necessary, and not in any case sufficient for its apparent purpose.
>
>
> `noalias` is not a property of an object, but in C++ we have references, and `unique_referable` is essentially a property of a reference.
> This is exactly like the distinction between a `prvalue` and it's result object. Therefore I don't think the same argument applies for this "variant" of the idea.
>
>
>>> 1. Allow more aggressive copy elision rules:
>>> ```c++
>>> pair<non_copyable, int> mrv_function()
>>> {
>>> unique_referable non_copyable a = {};
>>> //fill a
>>> return {a, 42}; //OK: copy elision is mandatory here
>>> }
>>> ```
>>> The rules to allow this are completely analogous to `prvalue` materialization conversion, only we delay materialization for an lvalue.
>>
>>
>> You seem to be assuming that `return {non_copyable{}, 42}` works with std::pair today. It does not, because std::pair is not an aggregate.
>> https://godbolt.org/z/x6fWEW
>> So forget #1; your proposal doesn't solve it.
>
>
> You are correct about `std::pair`, my mistake. Consider instead any aggregate type, and the point still stands.

What you want is not *generally* possible.

An aggregate is not allowed to initialize its objects out of order.
The named variable was initialized before the rest of the aggregate
members. Therefore, what you've suggested could only be possible via
pre-initializing the aggregate's member. And that only makes sense if
you are doing this with the first member of the aggregate. For any
other member, such pre-initialization can't be done because it would
be done out of order.

Personally, overcomplicating the language in this way just to stick an
aggregate at the end of the function instead of in the middle isn't a
good look for the language. This problem can be solved adequately with
the tools the language already has, so let's not

Also, what you want could *only* work on aggregates, to the extent it
works on them at all.