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.
