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

[bitwise]

On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote:

> Walter and Andrei have declined to accept DIP 1016, "ref T 
> accepts r-values", on the grounds that it has two fundamental 
> flaws that would open holes in the language.


> fun(10)
> ==>
> {
>   T __temp0 = void;
>   fun(__temp0 := 10);
> }

> the rewrite is from an expression to a statement, rendering it 
> invalid.

> if the first constructor throws an exception, all remaining 
> values will be destroyed in the void state as they never have 
> the chance to become initialized.

> They say that with the current semantics, this function only 
> operates on long values as it should. With the proposed 
> semantics, the call will accept all shared integral types.

I think this solves all of the above:

fun(10);
==>
(int __temp0){ (return)? fun( __temp0 ); }(10);

-The expression/statement issue is solved by the closure
-The initialization issue created by the ":=" approach is not 
present here
-For this rewrite, 'T' is the type of the rvalue argument, not 
the type of the function parameter. This prevents undesired 
implicit conversions.