www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - My thoughts & tries with rvalue references

reply "Namespace" <rswhite4 googlemail.com> writes:
Hey guys,
I would like to show you my tries and thoughts about rvalue 
references and their syntax.
As discussed in my other thread in the learn group 
(http://forum.dlang.org/thread/uswucstsooghescofycp forum.dlang.org?page=2#post-mailman.294.1364252397.4724.digitalmars-d-lea
n:40puremagic.com), 
auto ref is not longer an option for non-template functions.
Because of that I learned to read the compiler code and start my 
own tries, as you can read in my thread also 
(http://forum.dlang.org/thread/uswucstsooghescofycp forum.dlang.org?page=3#post-jrksuqqremsqgicmybri:40forum.dlang.org).
One of my tries was a kind of pseudo-property " ref" and finally 
a hybrid of D and C++: ref&.
Because I think a property isn't the best solution, I like to 
hear your thougths about my idea with "ref&".
Here a small example:

void bar1(ref& A a) { } // OK
void bar2(ref &A a) { } // OK
void bar21(&A a) { } // Error: '&' can only be used in 
combination with 'ref'.
void bar22(& A a) { } // Error: '&' can only be used in 
combination with 'ref'.
void bar3(ref const& A a) { } // OK
void bar4(ref const &A a) { } // OK
void bar5(ref &const A a) { } // Error: '&' Must be directly used 
in front of the type.
void bar6(ref& const A a) { } // Error: '&' Must be directly used 
in front of the type.

And for templates:

void foo(T)(ref &T t) { }

As you can see, '&' can only be used in front of the type and 
cannot exist without 'ref'.

The advantages of this syntax would be:
  - it is short
  - It is easy to implement
  - it is known from C++
  - It does not cause conflicts with other things
and it is (IMO) a very nice hybrid of C++ ref and D ref.

Hope you like it, just like me. But I would like to hear your 
general opinions about it.
Thanks in advance.
Mar 29 2013
next sibling parent reply "Zach the Mystic" <reachzach gggggmail.com> writes:
On Friday, 29 March 2013 at 13:45:48 UTC, Namespace wrote:
 Hey guys,
 I would like to show you my tries and thoughts about rvalue 
 references and their syntax.
 As discussed in my other thread in the learn group 
 (http://forum.dlang.org/thread/uswucstsooghescofycp forum.dlang.org?page=2#post-mailman.294.1364252397.4724.digitalmars-d-lea
n:40puremagic.com), 
 auto ref is not longer an option for non-template functions.
 Because of that I learned to read the compiler code and start 
 my own tries, as you can read in my thread also 
 (http://forum.dlang.org/thread/uswucstsooghescofycp forum.dlang.org?page=3#post-jrksuqqremsqgicmybri:40forum.dlang.org).
 One of my tries was a kind of pseudo-property " ref" and 
 finally a hybrid of D and C++: ref&.
 Because I think a property isn't the best solution, I like to 
 hear your thougths about my idea with "ref&".
 Here a small example:

 void bar1(ref& A a) { } // OK
 void bar2(ref &A a) { } // OK
 void bar21(&A a) { } // Error: '&' can only be used in 
 combination with 'ref'.
 void bar22(& A a) { } // Error: '&' can only be used in 
 combination with 'ref'.
 void bar3(ref const& A a) { } // OK
 void bar4(ref const &A a) { } // OK
 void bar5(ref &const A a) { } // Error: '&' Must be directly 
 used in front of the type.
 void bar6(ref& const A a) { } // Error: '&' Must be directly 
 used in front of the type.

 And for templates:

 void foo(T)(ref &T t) { }

 As you can see, '&' can only be used in front of the type and 
 cannot exist without 'ref'.

 The advantages of this syntax would be:
   - it is short
   - It is easy to implement
   - it is known from C++
   - It does not cause conflicts with other things
 and it is (IMO) a very nice hybrid of C++ ref and D ref.

 Hope you like it, just like me. But I would like to hear your 
 general opinions about it.
 Thanks in advance.

The major downside is that if you don't come from C++ it's hard to understand why 'ref &' means what you propose. The major upsides are, as you mention, it's very concise and perfectly intuitive if you DO come from C++. In the spirit of trying to come up with something for comparison, the best attribute I've thought of so far is ' val': void bar1( val ref A a) { } The advantage is that it's consistent with my understanding of the general approach to adding things to D at this point. But that's also it's disadvantage: it's nothing more than a mundane attribute.
Mar 29 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 30.03.2013 11:12, schrieb Minas Mina:
 On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote:
 And to pull the reverse: Why should ' val ref' be more intuitive than
 ref&? Or why should be ' ref' more intuitive?
 What I mean by that:
 Both the Property as well as the hybrid path have their weaknesses and
 are not necessarily immediately obvious. But we should choose one of
 them and focus on this so that somebody can make a pull request for it.

Because & in C++ means "by ref". D has "ref" for that. So ref& doesn't make sense. One might think it as a double reference(?)

I have to agree on that. My first impression was that ref& is equal to c++11 && Kind Regards Benjamin Thaut
Mar 30 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 30.03.2013 12:04, schrieb Namespace:
 I have to agree on that. My first impression was that ref& is equal to
 c++11 &&

 Kind Regards
 Benjamin Thaut

Ok, it seems that I think differently. And what is the general opinion of '&A' instead of 'ref &A'? It has all the benefits that I described in my first post, but it may not be so confusing. If you like to ask "why not A&": That is more complex as it seems to be, a opinion which is shared by Jonathan. And I sincerely hope that no one is annoyed about my attempts to solve this problem.

No I highly appreciate it, that you are trying to solve the problem. The current state of the language on this is annoying and it needs to be fixed. I personally would like &A the question is if this is the "D-Way". Maybe we should add a new keyword like "vref" for "value reference". Kind Regards Benjamin Thaut
Mar 30 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 The major downside is that if you don't come from C++ it's hard 
 to understand why 'ref &' means what you propose. The major 
 upsides are, as you mention, it's very concise and perfectly 
 intuitive if you DO come from C++. In the spirit of trying to 
 come up with something for comparison, the best attribute I've 
 thought of so far is ' val':

 void bar1( val ref A a) { }

 The advantage is that it's consistent with my understanding of 
 the general approach to adding things to D at this point. But 
 that's also it's disadvantage: it's nothing more than a mundane 
 attribute.

Yes you're right. But I just think that a property does not make sense here, because we mix then two different things: storage classes and properties. This strikes me as wrong. When I implemented the pseudo-property ref, I realized this. It seemed inconsistent compared to the rest of the D syntax. And since D, syntactically as well as linguistically (D provides direct access to C / C++), is a descendant of C++, I'd prefer to take a kind of hybrid: ref&. And to pull the reverse: Why should ' val ref' be more intuitive than ref&? Or why should be ' ref' more intuitive? What I mean by that: Both the Property as well as the hybrid path have their weaknesses and are not necessarily immediately obvious. But we should choose one of them and focus on this so that somebody can make a pull request for it.
Mar 30 2013
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote:
 And to pull the reverse: Why should ' val ref' be more 
 intuitive than ref&? Or why should be ' ref' more intuitive?
 What I mean by that:
 Both the Property as well as the hybrid path have their 
 weaknesses and are not necessarily immediately obvious. But we 
 should choose one of them and focus on this so that somebody 
 can make a pull request for it.

Because & in C++ means "by ref". D has "ref" for that. So ref& doesn't make sense. One might think it as a double reference(?)
Mar 30 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Because & in C++ means "by ref".
 D has "ref" for that.

 So ref& doesn't make sense. One might think it as a double 
 reference(?)

You are undermining my authority. :P I choose ref& because it is a hybrid of the C++ ref style and D's ref style. That's what I said in my first post. And C++ has const& for that kind of problem. In C++ it means that it accept both, rvalues and lvalues, but in D not. So we shouldn't be that fussy. ;) Do you like ' ref' more? Or have you another idea? I could imagine that '&A' (without ref) would work too, but I think that the most of you will say "It's too cryptic. It's C++ style.". I opened this thread in the first place to get at all other opinions or ideas. And possibly that we might find a common solution that I would try to implement. So let's hear.
Mar 30 2013
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
Personally yes, I prefer  ref more. But you are right that it's 
not nice to be an annotation.
Mar 30 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I have to agree on that. My first impression was that ref& is 
 equal to c++11 &&

 Kind Regards
 Benjamin Thaut

Ok, it seems that I think differently. And what is the general opinion of '&A' instead of 'ref &A'? It has all the benefits that I described in my first post, but it may not be so confusing. If you like to ask "why not A&": That is more complex as it seems to be, a opinion which is shared by Jonathan. And I sincerely hope that no one is annoyed about my attempts to solve this problem.
Mar 30 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
As far as I studied the code, something like  ref isn't possible, 
because ref is already a keyword. Except as Pseudo-property. But 
this is a combination of ' ' and 'ref' so that both, ' ref' and 
'  ref' would be valid.
I still like the idea of '&A'.
Mar 30 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 No I highly appreciate it, that you are trying to solve the 
 problem. The current state of the language on this is annoying 
 and it needs to be fixed.

 I personally would like &A the question is if this is the 
 "D-Way". Maybe we should add a new keyword like "vref" for 
 "value reference".

 Kind Regards
 Benjamin Thaut

That's nice to hear. I was afraid I would be too intrusive on this. And I've finally did it: A& works now. It was a bit tricky, but now it works nicely. Here a quick example: void bar1(A& a) { } // OK void bar2(A&* a) { } // Error: '&' can not be used in combination with '*' void bar3(A*& a) { } // Error: '&' can not be used in combination with '*' void bar4(const A& a) { } // OK void bar5(ref A& a) { } // Error: conflicting storage class '&' and ref and for templates: void bar(T)(T& t) { writeln(t); } Thoughts?
Mar 30 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Saturday, 30 March 2013 at 13:07:44 UTC, Benjamin Thaut wrote:
 Am 30.03.2013 12:04, schrieb Namespace:
 I have to agree on that. My first impression was that ref& is 
 equal to
 c++11 &&

 Kind Regards
 Benjamin Thaut

Ok, it seems that I think differently. And what is the general opinion of '&A' instead of 'ref &A'? It has all the benefits that I described in my first post, but it may not be so confusing. If you like to ask "why not A&": That is more complex as it seems to be, a opinion which is shared by Jonathan. And I sincerely hope that no one is annoyed about my attempts to solve this problem.

No I highly appreciate it, that you are trying to solve the problem. The current state of the language on this is annoying and it needs to be fixed. I personally would like &A the question is if this is the "D-Way". Maybe we should add a new keyword like "vref" for "value reference". Kind Regards Benjamin Thaut

Although adding new keywords is not smiled upon at this point, it might actually be worth it in this case.
Mar 30 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Saturday, 30 March 2013 at 14:37:11 UTC, Namespace wrote:
 That's nice to hear. I was afraid I would be too intrusive on 
 this.
 And I've finally did it: A& works now. It was a bit tricky, but 
 now it works nicely. Here a quick example:

 void bar1(A& a) { } // OK
 void bar2(A&* a) { } // Error: '&' can not be used in 
 combination with '*'
 void bar3(A*& a) { } // Error: '&' can not be used in 
 combination with '*'
 void bar4(const A& a) { } // OK
 void bar5(ref A& a) { } // Error: conflicting storage class '&' 
 and ref

 and for templates:

 void bar(T)(T& t) {
 	writeln(t);
 }

 Thoughts?

It's esoteric, which is bad, but concise, which is good. I think perhaps the annoying aspect of this feature is how attractive it would be to just get the power of the feature implicitly without needing a new attribute or keyword. To get it implicitly, and only have an attribute for when you *don't want an rvalue, e.g.: void foo( lvalue ref T a) {} ...would break code, but is nonetheless less something to consider also.
Mar 31 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote:
 The major downside is that if you don't come from C++ it's 
 hard to understand why 'ref &' means what you propose. The 
 major upsides are, as you mention, it's very concise and 
 perfectly intuitive if you DO come from C++. In the spirit of 
 trying to come up with something for comparison, the best 
 attribute I've thought of so far is ' val':

 void bar1( val ref A a) { }

 The advantage is that it's consistent with my understanding of 
 the general approach to adding things to D at this point. But 
 that's also it's disadvantage: it's nothing more than a 
 mundane attribute.

Yes you're right. But I just think that a property does not make sense here, because we mix then two different things: storage classes and properties. This strikes me as wrong. When I implemented the pseudo-property ref, I realized this. It seemed inconsistent compared to the rest of the D syntax. And since D, syntactically as well as linguistically (D provides direct access to C / C++), is a descendant of C++, I'd prefer to take a kind of hybrid: ref&.

Just a technical point, I believe your use of the term "property" should be replaced with the term "attribute". means attribute, of which there are two kinds, built-in and user defined. Built-in attributes themselves are little more than keywords which haven't acquired "tenure", so to speak - the confidence of the language designers that they merit the full status of a no- keyword.
Mar 31 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Monday, 1 April 2013 at 00:37:07 UTC, Zach the Mystic wrote:
 Just a technical point, I believe your use of the term 
 "property" should be replaced with the term "attribute".   
 means attribute, of which there are two kinds, built-in and 
 user defined. Built-in attributes themselves are little more 
 than keywords which haven't acquired "tenure", so to speak - 
 the confidence of the language designers that they merit the 
 full status of a no-  keyword.

To be even more precise, some built-in attributes, such as 'ref', 'in', and 'out' function parameters, don't even require the and are indeed full-fledged keywords too.
Mar 31 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 It's esoteric, which is bad, but concise, which is good. I 
 think perhaps the annoying aspect of this feature is how 
 attractive it would be to just get the power of the feature 
 implicitly without needing a new attribute or keyword.

lvalues, you use 'ref' and if you don't care, you use the C++ style. I think that would be the best idea. But currently I have a problem with the implemenation of 'A&'. I do not know how to convey the fact that behind the type is a '&'. IMO the correct D way is to create a new type like TypePointer -> TypeRvRef. But my attempts failed so far to create such type. Because of that I decided to declare a boolean flag 'isRvRef' inside of the basic Type struct which I set to TRUE if a '&' is behind the type. This works and don't break any code but I think that should be fixed by someone with more knowledge. But I think also that this rvalue problem has a very low priority. So if we want to resolve this issue, then we need to do it yourself. If someone wants to help me, the code and the current solution is on github: https://github.com/Dgame/dmd/tree/rvalueRef
 To get it implicitly, and only have an attribute for when you 
 *don't want an rvalue, e.g.:

 void foo( lvalue ref T a) {}

 ...would break code, but is nonetheless less something to 
 consider also.

Walter hate to break code, so the introduction of that would be even much less likely. And yes you're right, when I said 'property' I meant an attribute. ;)
Apr 01 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 But currently I have a problem with the implemenation of 'A&'. 
 I do not know how to convey the fact that behind the type is a 
 '&'. IMO the correct D way is to create a new type like 
 TypePointer -> TypeRvRef. But my attempts failed so far to 
 create such type.
 Because of that I decided to declare a boolean flag 'isRvRef' 
 inside of the basic Type struct which I set to TRUE if a '&' is 
 behind the type. This works and don't break any code but I 
 think that should be fixed by someone with more knowledge.
 But I think also that this rvalue problem has a very low 
 priority.
 So if we want to resolve this issue, then we need to do it 
 yourself.
 If someone wants to help me, the code and the current solution 
 is on github:
 https://github.com/Dgame/dmd/tree/rvalueRef

I could finally fix the problem. Now for rvalue references an extra type is created: TypeRvRef. But this solution does not work with templates. I do not yet know how to solve this, but maybe someone knows advice. Code: https://github.com/Dgame/dmd/tree/rvalueRef2
Apr 01 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I could finally fix the problem.
 Now for rvalue references an extra type is created: TypeRvRef.
 But this solution does not work with templates. I do not yet 
 know how to solve this, but maybe someone knows advice.
 Code: https://github.com/Dgame/dmd/tree/rvalueRef2

Since I still have no idea how to solve the template problem (I tried it the last 6 hours - without success) I have one final alternative: final ref. This would be as easy to implement as my first solution, but of course does not look that nice and is much longer than the C++ style. Any ideas? Opinions? Suggestions or ideas to solve the template problem are also welcome. :)
Apr 02 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 30 March 2013 at 12:00:32 UTC, Namespace wrote:
 As far as I studied the code, something like  ref isn't 
 possible, because ref is already a keyword. Except as 
 Pseudo-property. But this is a combination of ' ' and 'ref' so 
 that both, ' ref' and '  ref' would be valid.
 I still like the idea of '&A'.

I have to disagree with me here. Thanks to this thread (http://forum.dlang.org/thread/ohjdraaizvwiczifwrlk forum.dlang.org) I know now that after the ' ' can be an unlimited number of white spaces. Hence my previous speculation that I would have implemented something wrong is wrong. So is something like ' ref' possible and already implemented, as you can see here: https://github.com/Dgame/dmd/tree/rvalue_property I think this is probably the end result of my little journey. Any objections? Quick example: [code] struct A { public: ubyte id; this(ubyte id) { this.id = id; } this(this) { writeln("postblit of #", this.id); } } void foo( ref A a) { writeln(":: id = ", a.id); } void foo1( ref const A a) { writeln(":: id = ", a.id); } void foo2( ref shared A a) { writeln(":: id = ", a.id); } void foo3( ref immutable A a) { writeln(":: id = ", a.id); } // void foo4( ref lazy A a) { /// Error: incompatible parameter storage classes // writeln(":: id = ", a.id); // } // void foo5( ref ref A a) { /// Error: redundant storage class ref // writeln(":: id = ", a.id); // } // void foo6( ref out A a) { /// Error: incompatible parameter storage classes // writeln(":: id = ", a.id); // } void bar( ref int a) { writeln(a); } void quatz(T)( ref T t) { static if (is(T == struct)) writeln(t.id); else writeln(t); } [/code]
Apr 02 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--001a11c37e5c6660b004d9641721
Content-Type: text/plain; charset=UTF-8

I think 'scope ref' is better.
'in' = 'const scope', then 'in ref' = 'const scope ref'.

bool opEquals(in ref T rhs) const { ... }

Kenji Hara
2013/03/30 21:06 "Namespace" <rswhite4 googlemail.com>:

 As far as I studied the code, something like  ref isn't possible, because
 ref is already a keyword. Except as Pseudo-property. But this is a
 combination of ' ' and 'ref' so that both, ' ref' and '  ref' would be
 valid.
 I still like the idea of '&A'.

--001a11c37e5c6660b004d9641721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p>I think &#39;scope ref&#39; is better.<br> &#39;in&#39; =3D &#39;const scope&#39;, then &#39;in ref&#39; =3D &#39;cons= t scope ref&#39;.</p> <p>bool opEquals(in ref T rhs) const { ... }</p> <p>Kenji Hara</p> <div class=3D"gmail_quote">2013/03/30 21:06 &quot;Namespace&quot; &lt;<a hr= ef=3D"mailto:rswhite4 googlemail.com">rswhite4 googlemail.com</a>&gt;:<br t= ype=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"> As far as I studied the code, something like ref isn&#39;t possible, becau= se ref is already a keyword. Except as Pseudo-property. But this is a combi= nation of &#39; &#39; and &#39;ref&#39; so that both, &#39; ref&#39; and &#= 39; ref&#39; would be valid.<br> I still like the idea of &#39;&amp;A&#39;.<br> </blockquote></div> --001a11c37e5c6660b004d9641721--
Apr 02 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Tuesday, 2 April 2013 at 17:30:33 UTC, kenji hara wrote:
 I think 'scope ref' is better.
 'in' = 'const scope', then 'in ref' = 'const scope ref'.

 bool opEquals(in ref T rhs) const { ... }

 Kenji Hara
 2013/03/30 21:06 "Namespace" <rswhite4 googlemail.com>:

 As far as I studied the code, something like  ref isn't 
 possible, because
 ref is already a keyword. Except as Pseudo-property. But this 
 is a
 combination of ' ' and 'ref' so that both, ' ref' and '  ref' 
 would be
 valid.
 I still like the idea of '&A'.


As far as I know Jonathan was strict against it, or not? But that sounds and looks nice and would be very easy to implement.
Apr 02 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
My try for scope ref/in ref:
https://github.com/Dgame/dmd/tree/in_ref
Apr 02 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Tuesday, 2 April 2013 at 15:08:20 UTC, Namespace wrote:
 On Saturday, 30 March 2013 at 12:00:32 UTC, Namespace wrote:
 As far as I studied the code, something like  ref isn't 
 possible, because ref is already a keyword. Except as 
 Pseudo-property. But this is a combination of ' ' and 'ref' so 
 that both, ' ref' and '  ref' would be valid.
 I still like the idea of '&A'.

I have to disagree with me here. Thanks to this thread (http://forum.dlang.org/thread/ohjdraaizvwiczifwrlk forum.dlang.org) I know now that after the ' ' can be an unlimited number of white spaces. Hence my previous speculation that I would have implemented something wrong is wrong. So is something like ' ref' possible and already implemented, as you can see here: https://github.com/Dgame/dmd/tree/rvalue_property I think this is probably the end result of my little journey. Any objections?

' ref' is actually my least favorite choice. Of all presented, my two favorites are void func(ref& int a) {} void func( val ref int a) {} Hara Kenji's comment about 'scope ref' also raises the issue of just how subtle is the difference between this proposed feature and what 'auto ref' does in templates. Correct me if I'm wrong, but 'ref&' is proposed to have the compiler create a temporary at the call site and pass it as a reference. ref int func1(ref& int a) { return a; } // Example: int func2(ref int b) { return a; } int x = func2(func1(3)); The above passes because the temporary ref to "3" created for func1 survives the whole expression, I believe. func1 returns the 3 as a ref, which ref should not escape the original expression, but may escape func1 itself. So 'scope ref' cannot be used. 'scope ref' *could* be used for the related "performance ref" issue, wherein the compiler decides whether a ref or value is appropriate knowing full well there's no chance of escaping. There are actually three ref issues here. The performance ref issue is related to the compiler making automatic choices which have no affect on semantics. The other two issues are related to the Don't Repeat Yourself problem. 'auto ref' is the template solution which actually creates new functions depending on what is passed to it. The alternative solution is what's being proposed here, which I'll call the 'temp ref' solution. Instead of passing values to a custom created function, all rvalues are simply converted to temporary lvalues at the call site, with the caller responsible for tracking the value's scope. It might seem convenient to use the syntax 'auto ref' to tell a non-templated function to do this, but that syntax has been rejected for reasons I either never understood well enough or I've simply forgotten. All-in-all, the syntax 'ref &' seems harmless enough to me. As far as getting it to work with templates, the feature is clearly mutually exclusive with 'auto ref', but I'm not sure why any other usage would be a problem.
Apr 02 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Wednesday, 3 April 2013 at 01:19:18 UTC, Zach the Mystic wrote:
 On Tuesday, 2 April 2013 at 15:08:20 UTC, Namespace wrote:
 On Saturday, 30 March 2013 at 12:00:32 UTC, Namespace wrote:
 As far as I studied the code, something like  ref isn't 
 possible, because ref is already a keyword. Except as 
 Pseudo-property. But this is a combination of ' ' and 'ref' 
 so that both, ' ref' and '  ref' would be valid.
 I still like the idea of '&A'.

I have to disagree with me here. Thanks to this thread (http://forum.dlang.org/thread/ohjdraaizvwiczifwrlk forum.dlang.org) I know now that after the ' ' can be an unlimited number of white spaces. Hence my previous speculation that I would have implemented something wrong is wrong. So is something like ' ref' possible and already implemented, as you can see here: https://github.com/Dgame/dmd/tree/rvalue_property I think this is probably the end result of my little journey. Any objections?

' ref' is actually my least favorite choice. Of all presented, my two favorites are void func(ref& int a) {} void func( val ref int a) {} Hara Kenji's comment about 'scope ref' also raises the issue of just how subtle is the difference between this proposed feature and what 'auto ref' does in templates. Correct me if I'm wrong, but 'ref&' is proposed to have the compiler create a temporary at the call site and pass it as a reference. ref int func1(ref& int a) { return a; } // Example: int func2(ref int b) { return a; } int x = func2(func1(3));

s/ref int b/ref int a/
Apr 02 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 It might seem convenient to use the syntax 'auto ref' to tell a 
 non-templated function to do this, but that syntax has been 
 rejected for reasons I either never understood well enough or 
 I've simply forgotten.

 All-in-all, the syntax 'ref &' seems harmless enough to me. As 
 far as getting it to work with templates, the feature is 
 clearly mutually exclusive with 'auto ref', but I'm not sure 
 why any other usage would be a problem.

I like 'ref&' also, but the reaction seemed to imply that it looks not like a temp ref, more like a double ref. So we came back to ' ref'. And in terms of 'scope ref': scope works currently only for delegates so you could customize the behavior of scope ref quite appropriately. 'scope ref' is my second favorite alternative. The ranking would be: 1. ref& 2. scope ref / ref in 3. ref For all of these a proposal and a finished implementation of mine is ready, you have to choose and to review only. :)
Apr 02 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
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?
Apr 03 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
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 am against introducing new one-symbol meanings, it always looks like a hack. scope ref is much more elegant but I still can't get straight in my mind what this combination does mean from the abstract type system point of view.
Apr 03 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Wednesday, 3 April 2013 at 18:06:36 UTC, Dicebot wrote:
 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 am against introducing new one-symbol meanings, it always looks like a hack. scope ref is much more elegant but I still can't get straight in my mind what this combination does mean from the abstract type system point of view.

So you were against the introduction of ravalue references or do you just have a problem with the syntax?
Apr 03 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I am against introducing new one-symbol meanings, it always 
 looks like a hack. scope ref is much more elegant but I still 
 can't get straight in my mind what this combination does mean 
 from the abstract type system point of view.

Addendum to scope ref: It could mean: "This ref parameter accepts also rvalues​​, because no reference can leave the scope". Therefore it is safe to pass a rvalue by ref.
Apr 03 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
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?
Apr 03 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
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/
Apr 03 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
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!
Apr 03 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
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.
Apr 03 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
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.
Apr 04 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
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.
Apr 04 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
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?
Apr 04 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 '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.

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.

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.

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.
Apr 04 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
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.
Apr 04 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I don't know. My opinion has no value here.

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.
Apr 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d04448131c7019d04d98b6b7f
Content-Type: text/plain; charset=UTF-8

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.

--f46d04448131c7019d04d98b6b7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div style>I also think writing DIP would be better.</div>= <div style><br></div><div style>I can tell some reasonable points about &#3= 9;scope ref&#39;.</div><div style>- &#39;in ref&#39; has been allowed from = 2.060 (<a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D8105">htt= p://d.puremagic.com/issues/show_bug.cgi?id=3D8105</a>)</div> <div style>- &#39;scope ref&#39; is still disallowed. (&quot;Error: scope c= annot be ref or out&quot;)</div><div style>- &#39;scope&#39; means &quot;th= e reference cannot escape from local scope&quot;.</div><div style>=C2=A0 An= d an rvalue reference cannot escape from passed function. There is consiste= nt semantics.</div> <div style>- &#39;in&#39; is equivalent to &#39;const scope&#39; (=C2=A0<a = href=3D"http://dlang.org/function.html">http://dlang.org/function.html )</a=
</div><div style>=C2=A0 So, &#39;in ref&#39; is equivalent to &#39;const s=

<div style>- Currently &#39;scope&#39; affects to delegate parameter. In ot= her cases, &#39;scope&#39; has no meaning.</div><div style><br></div><div s= tyle>I recognize that Jonathan had opposed to &#39;in ref&#39; because it h= ad supported just only &quot;const rvalue reference&quot; (like &#39;cosnt = T&amp;&#39; in C++). In D, &#39;const&#39; means physical const, so he has = thought that mutable rvalue reference should be supported in D.</div> <div style><br></div><div style>So, I think &#39;scope ref&#39; is good pro= posal against the Jonathan&#39;s objection.</div><div style><br></div><div = style><br></div><div style>Kenji Hara</div><div style><a href=3D"http://dla= ng.org/function.html"><font color=3D"#222222"><br> </font></a>2013/4/5 Dicebot <span dir=3D"ltr">&lt;<a href=3D"mailto:m.stras= hun gmail.com" target=3D"_blank">m.strashun gmail.com</a>&gt;</span></div><= div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-= left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D""><div class=3D"h5">On Thursday, 4 April 2013 at 14:43:26 UTC= , Namespace wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> On Thursday, 4 April 2013 at 07:52:51 UTC, Dicebot wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> After some thinking on topic I come to conclusion that rvalue refs _should_= be &quot;scope ref&quot; and stuff like &quot;ref int f( temp ref int x) {= return x; }&quot; is invalid. I can see no valid use case for such an erro= r-prone case. Contrary, &quot;scope ref&quot; feels just like it was design= ed for this task, also a good moment to actually define what &quot;scope&qu= ot; means.<br> </blockquote> <br> I am beginning to like scope ref also. It just fits.<br> Nice that we agree on that now - but I still miss Kenji&#39;s, Walters and = Andrei&#39;s blessing. Otherwise I think it would be ripe for a pull reques= t. Or there is any difficulty?<br> </blockquote> <br></div></div> I don&#39;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 &quot;scope&q= uot; currently is, how it combines with ref now, how it should combine, how= Andrei&#39;s DIP fits in the picture, how it fits overall type system, wha= t 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 ma= tter of agreement (with Andrei/Walter) about points stated in DIP.<br> </blockquote></div><br></div></div> --f46d04448131c7019d04d98b6b7f--
Apr 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--047d7b86db60c0943604d98b7e09
Content-Type: text/plain; charset=UTF-8

2013/4/5 Namespace <rswhite4 googlemail.com>

 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.

Timely guess. I roughly implemented it in my experimental branch. https://github.com/9rnsr/dmd/commits/new_inref I need more cleanup for it, but it would work as we expected. Kenji Hara --047d7b86db60c0943604d98b7e09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/4/5 Namespace <span dir=3D"ltr">&lt;<a href=3D"mailto= :rswhite4 googlemail.com" target=3D"_blank">rswhite4 googlemail.com</a>&gt;= </span><div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo= te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt= h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le= ft:1ex"> Hmm, I don&#39;t know if I could write a long and good text for the DIP. My= english is very limited and not free of failures.<br> I still had hoped that Kenji or some other find the time, to see over my co= de and to make a DIP/Pull Request.<br> </blockquote></div><br></div></div><div class=3D"gmail_extra">Timely guess.= I roughly implemented it in my experimental branch.<br></div><div class=3D= "gmail_extra"><br></div><div class=3D"gmail_extra"><a href=3D"https://githu= b.com/9rnsr/dmd/commits/new_inref">https://github.com/9rnsr/dmd/commits/new= _inref</a><br> </div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra" style=
I need more cleanup for it, but it would work as we expected.</div><div cl=

Hara</div> </div> --047d7b86db60c0943604d98b7e09--
Apr 04 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 4 April 2013 at 16:21:50 UTC, Namespace wrote:
 I don't know. My opinion has no value here.

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.

Well, I doubt there are that many native speakers here which will be shocked by bad English :) But if you gather all data mentioned (see also Kenji's comment), I can write DIP itself for you. Type system changes should be studied in smallest details as those have have very long term consequences and incredibly hard to replace with better solutions later.
Apr 04 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Well, I doubt there are that many native speakers here which 
 will be shocked by bad English :) But if you gather all data 
 mentioned (see also Kenji's comment), I can write DIP itself 
 for you. Type system changes should be studied in smallest 
 details as those have have very long term consequences and 
 incredibly hard to replace with better solutions later.

That sounds good. Then I will try over the weekend to collect all the necessary data and post them here. Then you can take a quick look, whether you have enough information or if I need a little late filing.
Apr 04 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 4 April 2013 at 16:31:06 UTC, kenji hara wrote:
 2013/4/5 Namespace <rswhite4 googlemail.com>

 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.

Timely guess. I roughly implemented it in my experimental branch. https://github.com/9rnsr/dmd/commits/new_inref I need more cleanup for it, but it would work as we expected. Kenji Hara

That works well. Thanks for your efforts.
Apr 04 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
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.

Perhaps they should, but at least I will give the use case I was thinking of. If you've got a large struct, you don't want to pass it by value. Say you've got two functions which process and return a Large, and they accept rvalue refs. It might not be too much to ask that a Large always be an lvalue, but let's say you want to pass it directly by value for some reason. struct Large { ... } ref Large process1( temp ref Large a) { return a; } ref Large process2( temp ref Large a) { return a; } Large* lar = &process2(process1(Large("Pass"," a ", "Large", "here"))); The use case would allow this to work. And with the kind of error checking suggested in DIP25, this kind of construction would not actually be error prone. 'lar' would be understood as locally derived and could not escape the function it was defined in. But to speak to your point, this kind of single expression chaining of ref functions might be so rare that there's no great reason to allow it in tandem with rvalues.
Apr 04 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Thursday, 4 April 2013 at 16:25:52 UTC, kenji hara wrote:
 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

My argument would be that 'scope ref' and ' temp ref' are two different horns of the same devil, really. The problem with ' temp ref' is that it's "syntax creep", adding a new storage class for limited reward. But 'scope ref' is equally problematic, because if it *does* allow returning the parameter by reference it will be deceptively different from simply what 'scope' would do. So the syntax creep would be replaced by the confusing nature of 'ref', 'scope', and 'scope ref': ref int func(ref int a) { return a; } // Okay ref int func2(scope int a) { return *new int; //return a; // No good, error: a is 'scope' } // Okay: 'scope ref' means something different from 'scope' ref int func3(scope ref int a) { return a; } ref int testFuncs(ref int y) { int x; return func(x); // Error: ref return assumed local as x return func(y); // Okay: y is from outside and returnable return func2(x); // Okay: 'scope' ensures x not returned return func2(y); // Okay return func3(x); // Error: ref return assumed local as x return func3(y); // Okay: y outside return func3(53); // Error: temp 53 is local } If 'scope' were defined as above, 'scope ref' could not be used to say that you *also* want the parameter to be 'scope' in addition to 'scope ref'. This leads into the remaining issue with DIP25, which is that 'scope' would be useful to tell the calling function that the passed-in variable will not be 'ref' returned, as in func2() above. DIP25 may want 'scope' to help add flexibility to what may or may not be returned. Dicebot's suggestion, that ref int func3(scope ref int a) {} above be banned from returning 'a', would solve this problem. In this case 'scope ref' would mean both 'scope' *and* ' temp ref'. It does however conflate the two features, making it impossible to return an rvalue ref parameter by ref. It may be that the cases where you actually *want* to return an rvalue ref parameter by reference are so rare that no one will miss that you can't do it. Or, conversely, it may be so rare that you want to specify 'scope' on your parameter in addition to 'scope ref' that no one will miss not being able to do that either. But one of these solutions must be accepted is 'scope ref' is to mean what is suggested. The other horn of the devil is to swallow the distasteful pill and allow ' temp ref', 'ref&', or some other "syntax creep".
Apr 04 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Friday, 5 April 2013 at 00:12:33 UTC, Zach the Mystic wrote:
 struct Large { ... }
 ref Large process1( temp ref Large a) { return a; }
 ref Large process2( temp ref Large a) { return a; }

 Large* lar = &process2(process1(Large("Pass"," a ", "Large", 
 "here")));

This is exactly type of code I consider to be bad style and want to see banned. Function that gets rvalue ref should never return it as it knows nothing about its lifetime. Actually, I can't even find scope definition for temporaries in dlang.org, but it is hardly a good thing to rely on anyway. Best is to assume that when function is gone, so is rvalue temporary. Your code begs for using plain refs and storing Large in a stack variable before calling function chain. May look a bit less convenient but much more reliable and understandable.
Apr 05 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Thursday, 4 April 2013 at 16:25:52 UTC, kenji hara wrote:
 I also think writing DIP would be better.
 ...

Btw, Kenji, what do you think about redefining "in" to "const scope ref" and allowing compiler to chose how variable exactly is passed ("auto ref" with no template bloat)? Within those restrictions plain values should be indistinguishable from const rvalue refs. Will make "in" also much more meaningful as a separate entity.
Apr 05 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 5 April 2013 at 07:48:38 UTC, Dicebot wrote:
 On Thursday, 4 April 2013 at 16:25:52 UTC, kenji hara wrote:
 I also think writing DIP would be better.
 ...

Btw, Kenji, what do you think about redefining "in" to "const scope ref" and allowing compiler to chose how variable exactly is passed ("auto ref" with no template bloat)? Within those restrictions plain values should be indistinguishable from const rvalue refs. Will make "in" also much more meaningful as a separate entity.

To change "in" from "const scope" to "const scope ref" is IMO a bad idea. It will break code and it's not intuitive. In my opinion we should use "ref" in combination with something else (in this case "scope"). But that is my personal opinion.
Apr 05 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Friday, 5 April 2013 at 08:35:03 UTC, Namespace wrote:
 On Friday, 5 April 2013 at 07:48:38 UTC, Dicebot wrote:
 On Thursday, 4 April 2013 at 16:25:52 UTC, kenji hara wrote:
 I also think writing DIP would be better.
 ...

Btw, Kenji, what do you think about redefining "in" to "const scope ref" and allowing compiler to chose how variable exactly is passed ("auto ref" with no template bloat)? Within those restrictions plain values should be indistinguishable from const rvalue refs. Will make "in" also much more meaningful as a separate entity.

To change "in" from "const scope" to "const scope ref" is IMO a bad idea. It will break code and it's not intuitive. In my opinion we should use "ref" in combination with something else (in this case "scope"). But that is my personal opinion.

How so? It does not break anything, as all "const scope" cases can be processed with "const scope ref", in fact, compiler should be allowed to degrade first to latter. Regarding meaning - if "scope ref" means permissive rvalues (mutable ones), then "const scope ref" means closer match for C++ "const &" - constant references that can't escape scope. I actually have an impression you do really want exactly "const scope ref" considering frequent references to C++. Tricky part as far as I can see is ABI - one needs to be able to accept both value and ref parameters within same function signature. Possible but may be too hacky to implement.
Apr 05 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 How so? It does not break anything, as all "const scope" cases 
 can be processed with "const scope ref", in fact, compiler 
 should be allowed to degrade first to latter. Regarding meaning 
 - if "scope ref" means permissive rvalues (mutable ones), then 
 "const scope ref" means closer match for C++ "const &" - 
 constant references that can't escape scope.

ref" would get then the error: "redundant storage class: ref" because 'in' would contains 'ref' already. That's the whole reason of my rejection. ;)
 I actually have an impression you do really want exactly "const 
 scope ref" considering frequent references to C++.

const ref'. Mutable rvalue references are absolutely useful. How did you get the idea?
Apr 05 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Friday, 5 April 2013 at 08:57:35 UTC, Namespace wrote:
 How so? It does not break anything, as all "const scope" cases 
 can be processed with "const scope ref", in fact, compiler 
 should be allowed to degrade first to latter. Regarding 
 meaning - if "scope ref" means permissive rvalues (mutable 
 ones), then "const scope ref" means closer match for C++ 
 "const &" - constant references that can't escape scope.

ref" would get then the error: "redundant storage class: ref" because 'in' would contains 'ref' already. That's the whole reason of my rejection. ;)

I am surprised to hear that redundant storage classes are considered an error by dmd :) Makes no sense for me, typical "generic code gen" use case story.
 I actually have an impression you do really want exactly 
 "const scope ref" considering frequent references to C++.

const ref'. Mutable rvalue references are absolutely useful. How did you get the idea?

Sorry then, I have misunderstood you then. I do want both "scope ref" and "const scope ref" too, but I was thinking that simple easy-to-use shortcut (in) should match most idiomatic and safe use case, and that should be "scope const ref". With an additional benefit of being able to replace values with refs transparently due to storage class/qualifier restrictions. I don't have strong opinion here, it is just an idea that came to my mind today and felt tempting ;)
Apr 05 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 I am surprised to hear that redundant storage classes are 
 considered an error by dmd :) Makes no sense for me, typical 
 "generic code gen" use case story.

 Sorry then, I have misunderstood you then. I do want both 
 "scope ref" and "const scope ref" too, but I was thinking that 
 simple easy-to-use shortcut (in) should match most idiomatic 
 and safe use case, and that should be "scope const ref". With 
 an additional benefit of being able to replace values with refs 
 transparently due to storage class/qualifier restrictions.

 I don't have strong opinion here, it is just an idea that came 
 to my mind today and felt tempting ;)

I like it also but was afraid that it could break user code. 'in ref' is allowed since 2.060 and many users use 'in' because it is shorter than 'const' and feels like the opposite of 'out'. :/ Otherwise that would be a good idea. Let's hear what Kenji says.
Apr 05 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--047d7b622926cb0bc804d99a0a26
Content-Type: text/plain; charset=UTF-8

I also think that we should not change current `in` meaning.
It is already used as the shorthand of `const` widely, and it has value
semantics (make a copy of given argument). That's the major motivation to
add new syntax "scope ref" and "in ref".

Kenji Hara


2013/4/5 Namespace <rswhite4 googlemail.com>

 I am surprised to hear that redundant storage classes are considered an
 error by dmd :) Makes no sense for me, typical "generic code gen" use case
 story.

Sorry then, I have misunderstood you then. I do want both "scope ref" and
 "const scope ref" too, but I was thinking that simple easy-to-use shortcut
 (in) should match most idiomatic and safe use case, and that should be
 "scope const ref". With an additional benefit of being able to replace
 values with refs transparently due to storage class/qualifier restrictions.

 I don't have strong opinion here, it is just an idea that came to my mind
 today and felt tempting ;)

I like it also but was afraid that it could break user code. 'in ref' is allowed since 2.060 and many users use 'in' because it is shorter than 'const' and feels like the opposite of 'out'. :/ Otherwise that would be a good idea. Let's hear what Kenji says.

--047d7b622926cb0bc804d99a0a26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I also think that we should not change current `in` m= eaning.<br></div><div>It is already used as the shorthand of `const`=C2=A0w= idely, and it has value semantics (make a copy of given argument). That&#39= ;s the major motivation to add new syntax &quot;scope ref&quot; and &quot;i= n ref&quot;.<br> </div><div><br></div><div>Kenji Hara</div></div><div class=3D"gmail_extra">= <br><br><div class=3D"gmail_quote">2013/4/5 Namespace <span dir=3D"ltr">&lt= ;<a href=3D"mailto:rswhite4 googlemail.com" target=3D"_blank">rswhite4 goog= lemail.com</a>&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> I am surprised to hear that redundant storage classes are considered an err= or by dmd :) Makes no sense for me, typical &quot;generic code gen&quot; us= e case story.<br> </blockquote> </div><a href=3D"http://dpaste.1azy.net/3ef7a084" target=3D"_blank">http://= dpaste.1azy.net/<u></u>3ef7a084</a><div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Sorry then, I have misunderstood you then. I do want both &quot;scope ref&q= uot; and &quot;const scope ref&quot; too, but I was thinking that simple ea= sy-to-use shortcut (in) should match most idiomatic and safe use case, and = that should be &quot;scope const ref&quot;. With an additional benefit of b= eing able to replace values with refs transparently due to storage class/qu= alifier restrictions.<br> <br> I don&#39;t have strong opinion here, it is just an idea that came to my mi= nd today and felt tempting ;)<br> </blockquote> <br></div> I like it also but was afraid that it could break user code. &#39;in ref&#3= 9; is allowed since 2.060 and many users use &#39;in&#39; because it is sho= rter than &#39;const&#39; and feels like the opposite of &#39;out&#39;. :/<= br> Otherwise that would be a good idea. Let&#39;s hear what Kenji says.<br> </blockquote></div><br></div> --047d7b622926cb0bc804d99a0a26--
Apr 05 2013
prev sibling next sibling parent "Zach the Mystic" <reachzach gggggmail.com> writes:
On Friday, 5 April 2013 at 07:45:33 UTC, Dicebot wrote:
 On Friday, 5 April 2013 at 00:12:33 UTC, Zach the Mystic wrote:
 struct Large { ... }
 ref Large process1( temp ref Large a) { return a; }
 ref Large process2( temp ref Large a) { return a; }

 Large* lar = &process2(process1(Large("Pass"," a ", "Large", 
 "here")));

This is exactly type of code I consider to be bad style and want to see banned. Function that gets rvalue ref should never return it as it knows nothing about its lifetime. Actually, I can't even find scope definition for temporaries in dlang.org, but it is hardly a good thing to rely on anyway. Best is to assume that when function is gone, so is rvalue temporary.

It may be bad style. (I don't know if it's bad style.) But there is significant thought (such as in DIP25) going into the idea that the programmer doesn't even *need* to track the lifetime of a reference, that the compiler can do it automatically. I don't think it's documented, but there is already an error issued for local variables which are returned by reference, which is the same behavior as 'scope' described. ref int func() { int y; return y; // Error: may not be escaped } There is no current checking, however, for returning the result of a function which returns ref. ref int func(ref int a) { return a; } ref int func2() { int x; return func(x); // Passes when it should error, x escaped } DIP25, to be on the safe side, proposes that since func() takes a ref, it must be assumed to return the ref it takes. So func(x) will be treated as a local since x is a local. The only flaw with DIP25 is that it's actually *too* safe, and it will shut down some cases which are perfectly fine: ref int copy(ref int a) { int *b = new int; *b = a; return *b; // return by ref } I have tried to address this issue elsewhere (and I actually need to make formal proposals which I haven't done yet), but the main point is that even accepting a temporary rvalue is the kind of thing which can be tracked at the call site, and not the function itself. ref int func(ref int a) { return a; } ref int func2() { int x; return func(x); // Error, according to DIP25 return func(25); // Error also, temp 25 is local, just like x static int* y; return func(y); // Okay because y is not local } So there are two different issues going on. Now what's the big deal, you may ask. Any function designed to accept an rvalue temporary can't possibly want to return that parameter by reference. And you may be right. In fact, the only reason I know to allow it was mentioned above, because it would allow efficient chaining of operations on a single entity passed by reference instead of by value, with each function modifying it before passing it on. But it's the *caller* who needs to know how local the reference is, not the receiving function. And that leads me into the other issue, which is that I had thought 'scope' would be a great way to tell a calling function "no, this ref will not be returned to you". (This is the issue I need to make a formal proposal on.) And that leads to a direct contradiction with the proposed use of 'scope ref', as I have written in my answer to Kenji Hara's defense of 'scope ref'. ref int func(scope int a) { return *new int; // Okay return a; //Error: can't return a parameter marked scope } Now the checking used by DIP25 could call func() safely: ref int testFunc() { int x; return func(x); // Okay, I know x will not be returned } So 'scope' and 'scope ref' would mean two different things, and there might be some cases where you only want one of the features and not both. To address this issue, I thought of a slightly desperate way to actually resolve this problem without any new storage class, such as 'ref&' or ' temp ref'. In order to indicate 'scope' in addition to 'scope ref', you'd simply write 'scope scope ref'. Two scopes! The defense of this position is that the actual use of 'scope' by itself would rarely be used, and so the strange appearance of two scopes would almost never happen.
 Your code begs for using plain refs and storing Large in a 
 stack variable before calling function chain. May look a bit 
 less convenient but much more reliable and understandable.

Yes, this issue would be simplified by simply saying that any function which accepts rvalue temporaries must treat those parameters as locals and not allow returning them. It imposes a minor inconvenience on the programmer who must declare an lvalue to use any function which *does* return a reference to the parameter. I actually think this is a sound design choice, but at least it will be a choice and not a "lucky" accident. One last thing about 'scope ref', which would be usable for the new feature, assuming the design choice just mentioned was accepted. It's not as obvious that it implicitly allows rvalue temporaries as something blunt like ' temp ref' would be, or as inconspicuous as 'ref&' would be. Also, it sort of suggests that ordinary 'scope' is not in fact passed by ref, which I is somewhat misleading. So it does save on syntax creep, but it also has those three disadvantages. I think that's all I have to say about this topic!
Apr 06 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 6 April 2013 at 07:50:10 UTC, Zach the Mystic wrote:
 ...

allow them in safe and I hate safe as much. Type system will lack plain "non-null pointer" type then. Sad I can do nothing about it.
Apr 06 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
I am currently in the process to collect the necessary 
information and would gladly give you the previous data. Then you 
could already take a look on it, if you still need something or 
if something is missing and if, what. Then I have a clearer idea. 
That would certainly be very nice of you.
For this purpose it would be good to have your email. Or should I 
post the DIP proposal here?
Apr 06 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Saturday, 6 April 2013 at 17:50:31 UTC, Namespace wrote:
 I am currently in the process to collect the necessary 
 information and would gladly give you the previous data. Then 
 you could already take a look on it, if you still need 
 something or if something is missing and if, what. Then I have 
 a clearer idea. That would certainly be very nice of you.
 For this purpose it would be good to have your email. Or should 
 I post the DIP proposal here?

m.strashun at gmail
Apr 06 2013