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

[Don]

On Wednesday, 30 January 2019 at 03:01:36 UTC, 12345swordy wrote:
> On Wednesday, 30 January 2019 at 00:25:17 UTC, Don wrote:
>> But what I fail to see is why can't the programmer solve this 
>> themselves instead of relying on a new feature that would 
>> cause more harm?
>
>> Donald.
>
> ...Did you even read the arguments in the dip? This has been 
> discuss quite a lot in the forums, it even gives you links to 
> them.

Well, I read the DIP and the whole forum discussion back in the 
day, and again I think this will create more harm than benefits 
the way it was proposed.

And starting from the beginning of this DIP - Rationale example:

    "void fun(int x);

     fun(10); // <-- this is how users expect to call a typical 
function
     But when ref is present:

     void fun(ref int x);

     fun(10); // <-- compile error; not an lvalue!!
     Necessitating the workaround:

     int temp = 10;
     fun(temp);

     This inconvenience extends broadly to every manner of rvalue 
passed to
     functions, including:"

So the solution in the way I understood is pretty much a syntax 
sugar, creating temporary variable with destruction.

But the concept is weird, because originally your function 
signature has a "ref parameter" and we're just creating a 
workaround expanding it to handle rvalues.

I would prefer to handle it myself with overloading instead of 
being presented with new language feature creating different 
scenarios for something that's not the case right now.

Otherwise D will be pretty much like C++ and in this case why 
bother with it?

Donald.