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.
