DIP 1016--ref T accepts r-values--Community Review Round 1

Manu turkeyman at gmail.com
Fri Jul 20 17:41:13 UTC 2018


On Fri, 20 Jul 2018 at 03:55, Petar via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Friday, 20 July 2018 at 05:16:53 UTC, Mike Parker wrote:
> > This is the feedback thread for the first round of Community
> > Review for DIP 1016, "ref T accepts r-values":
> >
> > https://github.com/dlang/DIPs/blob/725541d69149bc85a9492f7df07360f8e2948bd7/DIPs/DIP1016.md
> >
> > All review-related feedback on and discussion of the DIP should
> > occur in this thread. The review period will end at 11:59 PM ET
> > on August 3, or when I make a post declaring it complete.
> >
> > At the end of Round 1, if further review is deemed necessary,
> > the DIP will be scheduled for another round. Otherwise, it will
> > be queued for the Final Review and Formal Assessment by the
> > language maintainers.
> >
> > Please familiarize yourself with the documentation for the
> > Community Review before participating.
> >
> > https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
> >
> > Thanks in advance to all who participate.
>
> First of all, I'm very glad to see Manu's persistence turn to
> fruition and by incorporating all the feedback so far, I think we
> have a very solid proposal.
>
> One question:
>
> > It is important that `T` be defined as the argument type [..]
>
> I think this should say that `T` is defined as the *parameter*
> type.

You're exactly right!
I'll fix it.

This is what I would expect to happen for `void fun(ref int
> x, ref long y, ref double z)`:
>
> ```
> fun(short(1), byte(2), int(3));
> ```
>
> =>
>
> ```
> {
>      int    __fun_temp0 = void;
>      long   __fun_temp1 = void;
>      double __fun_temp2 = void;
>
>      fun(
>          __fun_temp0 := short(1),
>          __fun_temp1 := byte(2),
>          __fun_temp2 := int(3)
>      );
> }
> ```

Precisely. I just used the wrong word!


> One other subtle point is that the order of declaration of the
> temporaries determines their lifetime, so we must be careful with
> that. In fact I think that we should define it so declaration and
> initialization are not separated and simply make the order of
> declaration match the function argument evaluation order.

Consider that we were calling a normal function:
  fun(T(x, y), gun(10, obj.prop), makeThing());

ref aside, the initialisation order of the temporaries should exactly
match the initialisation and/or evaluation order of args to regular
functions.

For instance, with an expression (x and y are objects):
    T x, y;
    fun(x + y)  -- becomes --> fun(T(x + y))
Ie, the construction should be incorporated into the usual argument
evaluation expression, and evaluated at the normal time.

I'm not sure if that evaluation order is spec-ed, or just
implementation defined?
Whichever it is, we much match that.

Can you propose text I could use to this effect? Add a PR with that
sentence if you like?


More information about the Digitalmars-d mailing list