On 4/23/13 2:00 PM, Manu wrote:
On 24 April 2013 03:15, Andrei Alexandrescu
<seewebsiteforem...@erdani.org <mailto:seewebsiteforem...@erdani.org>>
wrote:
"scope" is a keyword, not a language feature. In case you are
referring to scope variables, the feature "scope ref" has little to
do with it.
How so? 'scope' simply promises that a variable may not escape its
scope, no?
I think it's important to recognise it as 'scope' + 'ref', the 2 don't
have any special meaning when put together, just the logical compound,
which allows for a safe situation for temporaries that wasn't previously
available.
I understand. This could surely be used as an appeal to intuition for
the added feature, but it's in no way a justification that it's not a
new feature.
Many details are missing. This is not a simple problem.
So what are some others?
Returning a reference is an important topic.
An r-value passed this way produces a
temp, which is a stack variable. It's life is identical to any other
stack variable, ie, it lives for the life of the function where
it appears.
That's a possibility, but it's a departure from current semantics
and is not mentioned in the DIP.
I think it's presumed in the DIP, and it's certainly how Kenji
implemented it.
What 'current' semantic is it a departure from? The one where passing a
literal produces a compile error? Certainly, that's the point.
Currently, rvalues exist until they have been consumed by a call. By DIP
36, some rvalues exist through the end of the function.
auto-ref on the other hand IS a new feature (in this context),
and it
also makes no sense if you ask me. It's a template concept which
is not
applicable here.
It is a feature that has been implemented and works, just not in all
cases.
This isn't a 'case'. It's a separate issue.
Safely passing a temp to a ref function arg, and whether a template
argument is automatically determined to be ref or not are barely related
problems.
I still can't see how auto-ref has any business in this context.
They are related inasmuch they solve the same problem (define a function
that accepts both lvalues and rvalues). They are distinct because
currently in a template you could at least in theory figure out whether
the function has been called with an lvalue on rvalue. The code below
does not currently work but could be made to work:
void fun(T)(auto ref T t)
{
static if (is(t == ref)) {}
}
If we decide this feature is unnecessary (as I suspect is the case), we
should change the implementation of auto ref to only use one body for
both ref and non-ref versions.
In particular we are much more inclined to impart real,
demonstrable
safety to "ref"
ref is unsafe by definition.
We want to aim at making ref safe, thus making it useful as
restricted pass-down pointers. For full possibilities, one should
use pointers.
Okay, I'm good with that too, but how is that intended to work?
If the intent is to make ref escaping disallowed by default, that is a
major breaking change...
Walter and I are inclined to take the hit because we believe the upside
is worth it.
Can we start talking about virtual-by-default again while we're at it?
There are no plans to change that.
I don't believe this is possible without
some further justification.
The justification is that unsafe uses of ref are few and
uninteresting (they can be replaced with pointers). It would be very
powerful to be able to guarantee that safe code can use ref.
Again, this sounds like a major breaking change.
Why is scope-ref inferior? It's more informative, and offers more
flexibility (ie, the option of ref with or without scope)
Whether scope ref is inferior to the ref/auto ref combo is a judgment
call. On the face of it, any new feature has to prove its utility so it
starts from a somewhat disadvantaged position.
DIP36 however creates a situation where it's known that passing
a temp
is actually safe.
and to make "auto ref" work as a reference that can bind to
rvalues
as well as lvalues.
What does it mean to make a reference bind to r-values aswell as
l-values? Lots of people keep saying this too, but it doesn't really
make sense to me either.
I don't understand the question as the answer is in it.
No reference can bind to r-values, r-values can not be addressed.
This is a matter of language definition. Rvalues can be bound to
references today, and the bound references can be addressed.
struct S { void fun() { writeln(&this); } }
unittest { S().fun(); }
But auto ref and scope ref do bind to r-values.
It's
really a temp copy of said r-value that we're dealing with,
which is an
l-value, ie, a local with a lifetime that's unsuitable for
passing by
non-scope-ref.
scope-ref would promise that it won't escape the callee, and thus is
safe to pass a temp.
Our aim is to have ref make that promise.
ref is fundamentally broken in D right now. DIP36 creates a
situation
where it could be fixed.
A new feature is not a fix.
If scope is a new feature, then the keyword shouldn't compile and
pretend that it does stuff.
You are confusing a feature with a keyword. A given keyword may support
many features, e.g. static, final etc.
It's an incomplete/unimplemented feature, not a new one.
People are aware of it, they can write code that presumes it's present
and working. It compiles successfully.
I would personally take DIP36 one step further,
and ban all local's from being passed to non-scope ref.
Yes, a breaking change, but you could argue that any code that
passes a
stack variable to any ref arg is already broken. But this can be
addressed in a future DIP.
...perhaps I'm missing something fundamental in DIP36, or about
'auto ref'?
I can't understand why there seem to be 2 polarised parties on this
issue, which appear to see the problem completely differently,
and can't
visualise the counter perspective at all.
DIP36 should be closed. We must focus on making ref safe and on
making auto ref work with non-templates.
I'm fine with that, but it sounds like a massive breaking change.
However upon the presumption of this new goal, I don't see the relevance
of auto-ref anymore? Why continue to bring it up?
If ref is safe, nothing else is needed.
auto ref is needed to accept rvalues.
Andrei
