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

[Vijay Nayar]

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).