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