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

[Paolo Invernizzi]

On Wednesday, 25 July 2018 at 13:36:38 UTC, 12345swordy wrote:
> On Wednesday, 25 July 2018 at 12:40:16 UTC, Paolo Invernizzi 
> wrote:
>
>> That proposal is a 'Syntactic Sugar' feature, that simply hide 
>> what normally need to be explicitly coded: proved a temp 
>> rvalue, pass it to a callable taking ref. What you call 
>> 'simplification', I call it 'obfuscation'; what you call 
>> uniformity I call trying to spread a well justified 
>> restriction...
>> /Paolo
>
> A restriction which causes pointless redundant code for the 
> caller who doesn't always have source code access. If my old 
> teacher assistant taught me anything it is this: Redundant code 
> is bad. You are literately forcing the programmer to create tmp 
> variables that risk the possibility of being shadowed or worse, 
> having its value change.

That's an opinion, naturally.

What it's "pointless redundant" for you, it is let's "let's force 
the programmer to think about what he is doing, passing an rvalue 
by ref" for me, at least.

At best, is "let's catch early some bugs (caused by other 
problems as Manu pointed out)", but as Jonathan states.

> Your manual solution suggestion have it own set of problems.

Set of problems as automatic promotion or conversion, as decades 
of problems with unsigned/signed have proved...

> You might as well argue against the foreach statement, because 
> its "obfuscation"

There's not a magic conversion between apples and oranges in a 
foreach loop... ref value apart.

/Paolo