On 4/23/13 12:04 PM, Manu wrote:
On 24 April 2013 00:24, Andrei Alexandrescu
<[email protected] <mailto:[email protected]>>
wrote:
The very point of this DIP is to not create
syntax-driven features, instead better define existing ones that
make
sense on their own so they can be used for same purpose.
It's a new feature, no two ways about it. It overlaps ref and auto
ref without any palpable benefit and defines yet another way to
achieve the same thing as auto ref. On this ground alone the
proposal has a large problem.
How does it overlap ref? It simply justifies the argument with an extra
constraint and isn't tied to 'ref' at all, it's just useful in conjunction.
The best setup would be:
1. To take lvalues by reference, write "ref".
2. To take lvalues and rvalues by reference, write "auto ref".
Everything else is superfluous and puts the burden of justification on
the proposer. With DIP36, the setup would be:
1. To take lvalues by reference, write "ref".
2. To take lvalues and rvalues by reference:
2.1. Is it a template? Then write "auto ref".
2.2. Is it a non-template? Then write "scope ref".
I can't agree that it overlaps auto-ref at all. They're fundamentally
different concepts. auto-ref is a template concept; it selects the
ref-ness based on the received arg. 'auto ref', ie, 'automatic
ref-ness'. It makes no sense on a non-template situation.
I'm still completely amazed that the very reason this DIP makes perfect
sense to me(/us) is the same reason you have a problem with it.
I don't know how to respond to this. To me is it painfully obvious DIP
36 is poor language design and fails to solve a variety of issues, such
as clarifying lifetime of temporaries, safety, and returning ref from
functions.
2. The proposal is sketchy and does not give many details,
such as the
lifetime of temporaries bound to scope ref objects.
It can't because lifetime of temporaries is not defined in D at
all and
suck stuff needs to be consistent. It is not really different from a
lifetime of struct literal temporary used for pass-by-value.
A proposal aimed at binding rvalues to references must address
lifetime of temporaries as a central concern.
It's not an r-value, it's a standard stack-allocated temporary. It's
lifetime is identical to any other local.
The reason it's not detailed in the proposal is because it adds no such
new feature, and makes no changes. The lifetime of a local is well
understood.
Currently rvalues are destroyed immediately after the call they are
passed into. DIP 36 would need to change that, but fails to specify it.
3. The relationship with auto ref is insufficiently
described, e.g.
there should be clarification on why auto ref cannot be
improved to
fulfill the desired role.
auto ref is a template-world entity. If by "improved" you mean
"completely reworked" than sure, I can add this rationale. Will
do today.
I think we should focus on
http://d.puremagic.com/issues/__show_bug.cgi?id=9238
<http://d.puremagic.com/issues/show_bug.cgi?id=9238> and on making
ref safe.
I don't believe it's possible to make ref safe. Can you suggest any
vision for this?
http://d.puremagic.com/issues/show_bug.cgi?id=9238
It's unsafe by definition... you are passing a pointer of unknown origin
to a function that could do anything with that pointer.
Hence 'scope ref', which appropriately restricts what the callee is able
to do with it.
Our intent is to make "ref" always scoped and reserve non-scoped uses to
pointers. We consider this good language design: we have unrestricted
pointers for code that doesn't care much about safety, and we have "ref"
which is almost as powerful but sacrifices a teeny bit of that power for
the sake of guaranteed safety. Safety is guaranteed by making sure "ref"
is always scoped (references can be passed down but never escape their
bound value).
4. Above all this is a new language feature and again we want to
resort to adding new feature only if it is clear that the
existing
features are insufficient and cannot be made sufficient. In
particular
we are much more inclined to impart real, demonstrable
safety to "ref"
and to make "auto ref" work as a reference that can bind to
rvalues as
well as lvalues.
Can't agree. "scope" is defined (but not implemented, a pity).
Creating
temporaries already exists for some cases. No really new language
feature is added. No special syntax created. "scope ref" is still
"scope" and "ref" with all semantics this imposes, rvalue
references are
just a side-effect. Contrary to this, "auto ref" IS a new feature
created specifically for syntax hack. That is a very problem you are
speaking about - introducing new concepts instead of making use
of ones
that exist for ages.
You are of course to disagree, but that would make you wrong.
Explain why? Proclaiming he is simply wrong when he presents sound
reason isn't helpful.
I assumed it was obvious from what I'd already written. The claim has
been made that "scope ref" is not a new language feature. I don't know
how to reply to that other than, well, it is.
Andrei
