On Fri, Mar 19, 2021 at 12:48 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
>
>
What I want is to extend Copy Elision rules akin to P0889
<http://wg21.link/p0889>, maybe this is too ambitious.

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.
>

Fair enough. I do agree this may be overly complicated solution.
Thank you for the feedback, I will not pursue this idea further.

-- 
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>