On Wednesday, 3 April 2013 at 17:48:54 UTC, Namespace wrote:
It would interest me which of the suggestions would be rather
accepted.
- scope ref as Kenji suggested
- Or rather @ref because this is the way that D usually goes
when it comes to subsequent expansions.
What do you think?
I simply can't reconcile the stated intention of 'scope'
parameters with this feature. And '@ref' really makes no sense to
me, being even less intuitive than 'ref&'. My belief is that this
feature carries with it an inherent frustration because the
existing syntaxes can't accomodate it, each being just slightyl
off the mark, and to add a whole new keyword or '@' storage class
seems like not getting too much reward for the convenience the
feature provides.
'scope ref': The only existing documentation on scope parameters:
http://dlang.org/function.html suggests that references to them
simply cannot leave the function they find themselves in. But
this is *not* what the temp ref feature is about. Say you have
this temp ref function:
ref int func(@temp ref int a) { return a; }
According to the spec, it clearly violates 'scope', but is
nonetheless valid and safe, as far as I can tell. The compiler
can easily track the scope of a given lvalue at the call site:
static int* x;
static int y;
x = *func(3); // Error: result of func(3) is assumed to be local
x = *func(y); // Pass: address of y is known to be global
This kind of safety checking is not yet implemented, but is
suggested in DIP25, http://wiki.dlang.org/DIP25 . I believe it is
the right way to go. The locality of the return by reference is
assumed to be as local as the reference which is passed into it.
So the temp '3' reference would make the result of func(3) yield
a local, barring any other information which would allow the
compiler to safely assume otherwise. In essence, '@temp ref' can
escape its scope safely because the locality of the result is not
its responsibility.
As far as the fact that the meaning of 'scope' is not yet set in
stone and may change to adapt to new purposes, the question would
be whether its current definition is useful enough as is without
needing to expand it (rather counter-intuitively, to be honest)
to mean something different.
'@ref': I like this less than 'ref&' because it is even less
clear what it means than 'ref&' is. The two problems with 'ref&',
so far as I understand it, are 1, that it looks like a
one-character hack which generally not well-liked in this
community, and 2, it could be confused with a double-reference. I
personally don't think I'm going to confuse 'ref&' with 'ref *'.
At least 'ref&' gives a hint that it has something to do with
taking the address of something. '@ref' is nothing more than
saying, "Hey, I can take '@' and put it before keyword 'ref'.
Look at me!". I'm not for it at all.
If 'ref&' or '@ref' are rejected on the basis of their being
one-character hacks, then the search is on for a good '@' word or
an existing keyword which does the trick. I wish 'scope' could
cover it, but I personally don't see how that keyword as defined
covers this feature as proposed. I looked for other existing
keywords to do the job, but I didn't find one which met my
personal sense of what would work. 'auto ref' would have been a
perfect name for it if 'auto ref' hadn't already found great use
in templates. All I have, therefore, are '@val' and, given this
post, '@temp':
void func(@val ref int a) {}
void func(@temp ref int a) {}
I think '@val' is pretty good. I don't think this feature merits
its own keyword, so the '@' is there to stay, but at least '@val'
is only four letters long, exactly the same number of characters
as 'auto'.
Does anyone else have a better '@ttribute' for this feature,
assuming one-char hacks are out of the question?
