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

[Manu]

On Thu, Nov 8, 2018 at 3:10 AM Vijay Nayar via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Wednesday, 25 July 2018 at 21:55:00 UTC, Manu wrote:
> > On Wed, 25 Jul 2018 at 13:55, 12345swordy via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >>
> >> > It's not a false equivalence fallacy: all the discussion is
> >> > about IMPLICIT conversion or rvalues to lvalues.
> >> Yes it is, the issues regarding rvalue/lvalue conversion is
> >> not the same issues regarding the unsigned/signed conversion.
> >
> > I don't want to encourage this tangent, but I do want to say;
> > there's
> > no proposal of rvalue -> lvalue *conversion*.
> > The proposal is "ref accepts rvalues". There's no 'conversion'
> > anywhere in sight. That's not on the menu.
>
> I know this is kinda out of the blue, but I really like to use
> "in" and "out" to clarify my function interfaces.  "out" seems to
> imply "ref", but it also initializes the value to its .init value.
>
> Personally I don't get much mileage out of "out" assigning the
> ".init" value.  The same keyword though could be used to satisfy
> both major use cases.
>
> Maybe "ref" could accept rvalues as per the DIP, but "out ref"
> would not, allowing error checking for those who truly intend the
> argument to be used to store output (and this comes up a lot when
> a method needs to return multiple results).

I think it's reasonable that `out` could reject rvalues.