March 29, 2013
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
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
> 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
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
> 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
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
Personally yes, I prefer @ref more. But you are right that it's not nice to be an annotation.
March 30, 2013
> 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
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
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 6
Top | Discussion index | About this forum | D home