ref returns and properties

[Don]

Sean Kelly wrote:
> 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.

At least, it's something you could do in a lint tool. I think it would 
be a useful warning for classes.

It still wouldn't solve Andrei's problem, though, because you still need 
public fields of structs to be POD fields, and a struct can still have 
properties. Then there are module properties...



   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