On Wednesday, 24 June 2015 at 23:30:53 UTC, Jonathan M Davis
wrote:
On Wednesday, 24 June 2015 at 16:39:22 UTC, kink wrote:
On Wednesday, 24 June 2015 at 11:19:04 UTC, Jonathan M Davis
wrote:
[...]
3. Add a new attribute which does what's being proposed for
auto ref for non-templated functions, in which case, we can
use the non-templated behavior with templates as well and
thus avoid template bloat when all you want is for your
templated function to accept both lvalues and rvalues. auto
ref, of course, then stays exactly as it is now.
At the moment, it seems that #2 is the most likely, and
that's probably fine, but I do wonder if we'd be better off
with #3, especially when you consider how much D code tends
to be templated and how much code bloat auto ref is likely to
generate with templated functions.
- Jonathan M Davis
If that wasn't clear before, I'm all for #3 too. Just call it
`scope ref` and simplify the PR a lil' bit as suggested by
Marc in an earlier post
[http://forum.dlang.org/post/ricvtchihgzyisbkz...@forum.dlang.org].
But this has _nothing_ to do with scope, and scope ref was
already rejected. The whole point of this is support having a
function accept both rvalues and lvalues, not to do anything
with scope.
It everything to do with scope, and I already explained it
several times. As for the rejection, see my answer to Namespace:
http://forum.dlang.org/post/yxruhtwjllozgvpbh...@forum.dlang.org
And given that what scope does has never even been properly
defined - all that the spec says about scope parameters is
"references in the parameter cannot be escaped (e.g. assigned
to a global variable)"
Even this current vague definition is already enough of a
guarantee to allow rvalue references with it. Of course I'd be
the last to object against a more detailed specification,
obviously.
- and that the only place that scope does anything at all is
with delegates,
That's simply the status quo of the implementation and therefore
can't be used as an argument.
trying to expand it with "scope ref" as if that were simply an
extension of scope makes no sense. Before we can even consider
what something like scope ref might mean, we'd have to properly
define what scope means. And all we have for it is the basic
idea of what it's supposed to do - none of the details - and
trying to define scope ref before defining what scope means in
general could totally hamstring us when properly defining scope
later.
I can assure you that it will not limit us. The very concept of
borrowing/scope already requires some very specific restrictions
with regards to what a function is allowed to do with a scope
parameter. These same restrictions guarantee that it's allowed to
pass an rvalue to it. Every working scope proposal will always
guarantee that, or it wouldn't be usable.
If you still fear that it will impede us later, then at least
this current proposal needs to be deferred until we have a scope
proposal and have decided on it.
