DIP 1016--ref T accepts r-values--Formal Assessment
don at gmail.com
Wed Jan 30 04:34:46 UTC 2019
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?
> ...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
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
But when ref is present:
void fun(ref int x);
fun(10); // <-- compile error; not an lvalue!!
Necessitating the workaround:
int temp = 10;
This inconvenience extends broadly to every manner of rvalue
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?
More information about the Digitalmars-d-announce