My thoughts & tries with rvalue references
Zach the Mystic
reachzach at gggggmail.com
Sun Mar 31 17:37:06 PDT 2013
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.
More information about the Digitalmars-d
mailing list