View mode: basic / threaded / horizontal-split · Log in · Help
April 04, 2013
Re: My thoughts & tries with rvalue references
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
Re: My thoughts & tries with rvalue references
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
Re: My thoughts & tries with rvalue references
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
Re: My thoughts & tries with rvalue references
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
Re: My thoughts & tries with rvalue references
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
Re: My thoughts & tries with rvalue references
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
Re: My thoughts & tries with rvalue references
> '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
Re: My thoughts & tries with rvalue references
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
Re: My thoughts & tries with rvalue references
> 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
Re: My thoughts & tries with rvalue references
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.
>
1 2 3 4 5 6
Top | Discussion index | About this forum | D home