View mode: basic / threaded / horizontal-split · Log in · Help
March 29, 2013
My thoughts & tries with rvalue references
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-learn: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.
March 30, 2013
Re: My thoughts & tries with rvalue references
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-learn: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.
March 30, 2013
Re: My thoughts & tries with rvalue references
> 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.
March 30, 2013
Re: My thoughts & tries with rvalue references
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(?)
March 30, 2013
Re: My thoughts & tries with rvalue references
> 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.
March 30, 2013
Re: My thoughts & tries with rvalue references
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
March 30, 2013
Re: My thoughts & tries with rvalue references
Personally yes, I prefer @ref more. But you are right that it's 
not nice to be an annotation.
March 30, 2013
Re: My thoughts & tries with rvalue references
> 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.
March 30, 2013
Re: My thoughts & tries with rvalue references
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'.
March 30, 2013
Re: My thoughts & tries with rvalue references
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home