My thoughts & tries with rvalue references

Namespace rswhite4 at googlemail.com
Sat Mar 30 02:17:16 PDT 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.


More information about the Digitalmars-d mailing list