DIP 1016--ref T accepts r-values--Formal Assessment

Manu turkeyman at gmail.com
Thu Jan 31 01:55:07 UTC 2019


On Wed, Jan 30, 2019 at 12:40 PM 12345swordy via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> On Wednesday, 30 January 2019 at 18:29:37 UTC, Manu wrote:
> > On Wed, Jan 30, 2019 at 9:20 AM Neia Neutuladh via
> > Digitalmars-d-announce <digitalmars-d-announce at puremagic.com>
> > wrote:
> >>
> >> On Wed, 30 Jan 2019 09:15:36 -0800, Manu wrote:
> >> > Why are you so stuck on this case? The DIP is about
> >> > accepting rvalues,
> >> > not lvalues...
> >> > Calling with 'p', an lvalue, is not subject to this DIP.
> >>
> >> The result of a CastExpression is an rvalue. An implicit cast
> >> is a compiler-inserted CastExpression. Therefore all lvalues
> >> with a potential implicit cast are rvalues.
> >
> > But there's no existing language rule that attempts to perform
> > an
> > implicit cast where an lvalue is supplied to a ref arg...?
> > Why is the cast being attempted?
> Because of the rewrite that your proposed in your dip.
>
> void fun(ref int x);
>
> fun(10);
>
> {
>    T __temp0 = void;
>    fun(__temp0 := 10);
> }
>
> lets replace 10 with a short variable named: S

"a short variable named: S" is an lvalue, so why would the rewrite be
attempted? S must be an rvalue for any rewrite to occur. We're talking
about rvalues here.


More information about the Digitalmars-d-announce mailing list