On 04/23/2013 07:33 PM, Andrei Alexandrescu wrote:
On 4/23/13 12:04 PM, Manu wrote:
On 24 April 2013 00:24, Andrei Alexandrescu
<seewebsiteforem...@erdani.org <mailto:seewebsiteforem...@erdani.org>>
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".
or "scope ref", to be fair. scope ref on a template would behave
differently than auto ref on a template.
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.
+1.
...
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).
...
Safety should be guaranteed in @safe code. There is no point in
conservatively disallowing perfectly fine @system code on the basis of
safety concerns, unless, of course, the type system is advanced enough
to prove safe all relevant use cases.
