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