On 4/23/13 11:27 AM, Manu wrote:
On 24 April 2013 00:30, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
wrote:
On 4/23/13 10:05 AM, Manu wrote:
I can't see the fault in DIP36's reasoning. It just makes sense.
Why is
everyone so against it? I'm yet to understand a reason...
1. It defines a new language feature instead of improving the
existing ones. At this point in the development of the language, our
preference should be putting the existing features in good order.
I see it in exactly the opposite way.
This does put an existing feature in good order, ie, scope, which is
defined but barely implemented, and might as well have been invented for
this purpose as far as I can tell from what little information is
available about it.
"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.
2. The proposal is sketchy and does not give many details, such as
the lifetime of temporaries bound to scope ref objects.
Is that the only detail missing?
Many details are missing. This is not a simple problem.
An r-value passed this way produces atemp, 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.
It is a feature that has been implemented and works, just not in all cases.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.
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.
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.I don't believe this is possible without
some further justification.
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.But auto ref and scope ref do bind to r-values.
No reference can bind to r-values, r-values can not be addressed.
Our aim is to have ref make that promise.
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.
A new feature is not a fix.
ref is fundamentally broken in D right now. DIP36 creates a situation
where it could be fixed.
DIP36 should be closed. We must focus on making ref safe and on making auto ref work with non-templates.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.