ref returns and properties

[Sean Kelly]

Don wrote:
> Andrei Alexandrescu wrote:
>> Jacob Carlborg wrote:
>> [on properties]
>>> What about this:
>>>
>>> class Host
>>> {
>>>      property acquire release prop
>>>      {
>>>          T get();
>>>      }
>>> }
>>>
>>> And then the compiler will automatically created the "acquire" and 
>>> "release" methods.
>>>
>>> There could also be what I would like to call "property shortcuts" 
>>> (ruby calls this attributes) like this:
>>>
>>> class Host
>>> {
>>>      get acquire release T prop;
>>>      get set T prop2;
>>> }
>>
>> I was hoping I'd shield putative users from having to write verbose 
>> code. Besides, there's one other issue I stumbled upon while working 
>> on porting std.algorithm to ranges.
>>
>> You can't really pass an entire property to a function. This furthers 
>> the rift between properties and true fields. Consider:
>>
>> struct A { int x; }
>> void foo(ref int n) { if (n == 0) n = 1; }
>> ...
>> A obj;
>> foo(obj.x);
>>
>> So when passing obj.x to foo, foo can read and write it no problem. 
>> But if x is a property of A, it all falls apart: obj.x means just 
>> reading the property, not getting the property with all of its get and 
>> set splendor.
> 
> I'm starting to wonder if we need some restrictions on fields, in order 
> to make properties and fields interchangable.
> The idea that a field could eventually be completely replaceable with 
> functions is appealing, but I think it's only possible with a huge 
> performance hit. One can distinguish between POD fields (for which any 
> operation is legal) and property fields (which you cannot take the 
> address of, for example).
> Arguably classes should normally not contain public POD fields, only 
> public property fields. Perhaps this is a useful concept.

I'm hesitant to assert that it should be illegal to take the address of 
a public data member, but this is certainly an intriguing idea.  The 
only other option I can think of would be to make swap a built-in 
property of concrete types and expecting the user to call a.swap(b), 
though it seems weird that a.swap(b) couldn't be rewritten as swap(a,b) 
for any concrete type, regardless of context.


Sean