DIP 1016--ref T accepts r-values--Final Review

[Manu]

On Sun, Nov 18, 2018 at 8:00 AM Rubn via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Saturday, 17 November 2018 at 14:49:26 UTC, kinke wrote:
> > On Saturday, 17 November 2018 at 13:01:12 UTC, Rubn wrote:
> >> For this what about if there are multiple parameters? How many
> >> overloads do you have to define to get this behavior?
> >
> > I'd assume a single one. It should be analogous to this:
> >
> > ```
> > void lval_only(uint x, short y) @disable;
> > void lval_only(int x, int y);
> >
> > void main()
> > {
> >     byte y = 1;
> >     lval_only(100_000, y);
> > }
> > ```
> >
> > The disabled function is preferred, so this doesn't compile. As
> > by-value params are to be preferred for rvalue args in overload
> > resolution, the single overload should do in your example.
> >
> > ---
> >
> > I'm a huge fan of this DIP and have been wanting this in the
> > language literally since the day I wrote my first D code,
> > immediately stumbling into this limitation (but fortunately not
> > losing much interest due to numerous advantages and syntax
> > loveliness).
>
> If that's the case then it'll look something like this, for just
> 3 parameters if you want the old behavior:
>
>      void lval_only(int x, int y, int z) @disable;
>      void lval_only(int x, int y, ref int z) @disable;
>      void lval_only(int x, ref int y, ref int z) @disable;
>      void lval_only(ref int x, int y, ref int z) @disable;
>      void lval_only(ref int x, ref int y, int z) @disable;
>      void lval_only(int x, ref int y, int z) @disable;
>      void lval_only(ref int x, int y, ref int z) @disable;
>
>      void lval_only(ref int x, ref int y, ref int z);
>
> Not really ideal, I might be missing one, hard to tell.

Ideas to improve this are welcome; but let's be realistic, the thing
you describe has almost certainly *never* been deployed in practise in
any code anywhere at any time, and I can't imagine a use case.
The value in this DIP shouldn't be called into question because a
not-useful thing appears less convenient.
Meanwhile, the more-likely and simpler case (one argument, which
appears in properties and what not), becomes clearer and more
explicit.

If you have ideas to improve this multi-arg case, that's useful, but I
wouldn't lose sleep over this either way :)