'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 I know Andrei works on DIP25 and as far as I know from
his thread in D.bugs he has already began with the implementation.
But I agree with you that 'scope ref' should be smart enough to
detect case #2 and allow it.
'@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.
:D
Yes, there already is some truth to it.
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 think with Andreis improvements on the current ref
implementation, scope ref could do the job. It must only be smart
enough to detect such cases as you described above.
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?
I don't like @val because I don't see the coherence between
rvalue references and value references. Or I don't understand it
right now. But @temp would be a good alternative if some others
with more knowledge than me think also, that scope ref isn't the
right way to go and @ref/ref& are dirty hacks.
