On Saturday, 30 March 2013 at 09:17:17 UTC, Namespace wrote:
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&.
Just a technical point, I believe your use of the term "property"
should be replaced with the term "attribute". @ means attribute,
of which there are two kinds, built-in and user defined. Built-in
attributes themselves are little more than keywords which haven't
acquired "tenure", so to speak - the confidence of the language
designers that they merit the full status of a no-@ keyword.
