On Mon, 21 Aug 2023 at 15:57, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Any solution to a C++ problem that starts with "let's add a new
> reference type to the language" is not a solution worth having.
> There's really no point in considering it further.
>
> However, if this were to be entertained further, then some explanation
> of what's actually happening here is in order. You say that your new
> reference type means that the "argument must be a prvalue?". OK, but
> then you say "we need control over when the prvalue gets generated ".
>
> This makes no sense. The fact that a variable must be initialized by a
> prvalue doesn't change how variables work. "when the prvalue gets
> generated" happened *before the function call*. If you want it to
> happen differently from that, then you need to explain what those
> differences are and how that works. Are you saying that the parameter
> captures the entire expression, leaving it unevaluated until some time
> *within* the function (which is not what it means for a variable to
> "be a prvalue")? OK, so how does that work? Must the function be
> inlined? If not, how can a compiler pass *arbitrary code* to a
> concrete function that has no idea how any particular parameter was
> initialized?
>

That seems related to
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0927r2.pdf



>
> Overall, this idea doesn't even seem half-baked. I guess I shouldn't
> be surprised given the source.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>