April 04, 2013
On Thursday, 4 April 2013 at 01:07:08 UTC, Zach the Mystic wrote:
> 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

s/*func/&func/
April 04, 2013
On Wednesday, 3 April 2013 at 06:19:58 UTC, Namespace wrote:
> For all of these a proposal and a finished implementation of mine is ready, you have to choose and to review only. :)

Hot stuff!
April 04, 2013
On Thursday, 4 April 2013 at 01:07:08 UTC, Zach the Mystic wrote:
> '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.

On the other hand, a '@temp ref' parameter *should* be prevented from being assigned directly to a global, since it might be stack-allocated:

static int* x;
void func(@temp ref int a) {
  x = &a; // Error, 'a' might be stack-allocated
}

This *would* be an acceptable error. It's completely unsafe to assume that 'a' is located anywhere but the stack. But it's very different from a 'scope' parameter, which expressly forbids this, as opposed to the fortuitous coincidence that allows you to know that 'x = &a' is an error in this particular case. To have 'scope ref' implicitly mean '@temp ref' would be conflating two different features, I think, which only happen to have one thing in common.

April 04, 2013
After some thinking on topic I come to conclusion that rvalue refs _should_ be "scope ref" and stuff like "ref int f(@temp ref int x) { return x; }" is invalid. I can see no valid use case for such an error-prone case. Contrary, "scope ref" feels just like it was designed for this task, also a good moment to actually define what "scope" means.
April 04, 2013
On Wednesday, 3 April 2013 at 20:22:10 UTC, Namespace wrote:
> So you were against the introduction of ravalue references or do you just have a problem with the syntax?

I am against whole "ref" design in D and consider it a mistake :) But within current specification requirements - against "hacky" syntax, rvalue references are useful indeed.
April 04, 2013
On Thursday, 4 April 2013 at 07:52:51 UTC, Dicebot wrote:
> After some thinking on topic I come to conclusion that rvalue refs _should_ be "scope ref" and stuff like "ref int f(@temp ref int x) { return x; }" is invalid. I can see no valid use case for such an error-prone case. Contrary, "scope ref" feels just like it was designed for this task, also a good moment to actually define what "scope" means.

I am beginning to like scope ref also. It just fits.
Nice that we agree on that now - but I still miss Kenji's, Walters and Andrei's blessing. Otherwise I think it would be ripe for a pull request. Or there is any difficulty?
April 04, 2013
> '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.
April 04, 2013
On Thursday, 4 April 2013 at 14:43:26 UTC, Namespace wrote:
> On Thursday, 4 April 2013 at 07:52:51 UTC, Dicebot wrote:
>> After some thinking on topic I come to conclusion that rvalue refs _should_ be "scope ref" and stuff like "ref int f(@temp ref int x) { return x; }" is invalid. I can see no valid use case for such an error-prone case. Contrary, "scope ref" feels just like it was designed for this task, also a good moment to actually define what "scope" means.
>
> I am beginning to like scope ref also. It just fits.
> Nice that we agree on that now - but I still miss Kenji's, Walters and Andrei's blessing. Otherwise I think it would be ripe for a pull request. Or there is any difficulty?

I don't know. My opinion has no value here. I may advice to write a DIP that makes more accent on theoretical side of problem - what "scope" currently is, how it combines with ref now, how it should combine, how Andrei's DIP fits in the picture, how it fits overall type system, what are possible code breakage scenarios, what are typical use cases for this feature etc. If such DIP and matching pull request do exist, it is only matter of agreement (with Andrei/Walter) about points stated in DIP.
April 04, 2013
> I don't know. My opinion has no value here.
I know. But I wanted to hear just your personal opinion about the code and if you have any suggestions or anything.

> I may advice to write a DIP that makes more accent on theoretical side of problem - what "scope" currently is, how it combines with ref now, how it should combine, how Andrei's DIP fits in the picture, how it fits overall type system, what are possible code breakage scenarios, what are typical use cases for this feature etc. If such DIP and matching pull request do exist, it is only matter of agreement (with Andrei/Walter) about points stated in DIP.

Hmm, I don't know if I could write a long and good text for the DIP. My english is very limited and not free of failures.
I still had hoped that Kenji or some other find the time, to see over my code and to make a DIP/Pull Request.
April 04, 2013
I also think writing DIP would be better.

I can tell some reasonable points about 'scope ref'.
- 'in ref' has been allowed from 2.060 (
http://d.puremagic.com/issues/show_bug.cgi?id=8105)
- 'scope ref' is still disallowed. ("Error: scope cannot be ref or out")
- 'scope' means "the reference cannot escape from local scope".
  And an rvalue reference cannot escape from passed function. There is
consistent semantics.
- 'in' is equivalent to 'const scope' ( http://dlang.org/function.html
)<http://dlang.org/function.html>
  So, 'in ref' is equivalent to 'const scope ref'.
- Currently 'scope' affects to delegate parameter. In other cases, 'scope'
has no meaning.

I recognize that Jonathan had opposed to 'in ref' because it had supported just only "const rvalue reference" (like 'cosnt T&' in C++). In D, 'const' means physical const, so he has thought that mutable rvalue reference should be supported in D.

So, I think 'scope ref' is good proposal against the Jonathan's objection.


Kenji Hara

<http://dlang.org/function.html>2013/4/5 Dicebot <m.strashun@gmail.com>

> On Thursday, 4 April 2013 at 14:43:26 UTC, Namespace wrote:
>
>> On Thursday, 4 April 2013 at 07:52:51 UTC, Dicebot wrote:
>>
>>> After some thinking on topic I come to conclusion that rvalue refs _should_ be "scope ref" and stuff like "ref int f(@temp ref int x) { return x; }" is invalid. I can see no valid use case for such an error-prone case. Contrary, "scope ref" feels just like it was designed for this task, also a good moment to actually define what "scope" means.
>>>
>>
>> I am beginning to like scope ref also. It just fits.
>> Nice that we agree on that now - but I still miss Kenji's, Walters and
>> Andrei's blessing. Otherwise I think it would be ripe for a pull request.
>> Or there is any difficulty?
>>
>
> I don't know. My opinion has no value here. I may advice to write a DIP that makes more accent on theoretical side of problem - what "scope" currently is, how it combines with ref now, how it should combine, how Andrei's DIP fits in the picture, how it fits overall type system, what are possible code breakage scenarios, what are typical use cases for this feature etc. If such DIP and matching pull request do exist, it is only matter of agreement (with Andrei/Walter) about points stated in DIP.
>