ref returns and properties

[Don]

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.

Incidentally, a simpler way of bridging the divide would have been to 
drop property syntax and instead allow public fields to be accessed 
using function notation. Setting would be similar to C++ constructors:
int z = obj.x() + 7;
obj.x(6);


> How did this hit me in std.algorithm? Replace A with your range of 
> choice, x with head, and foo with swap. If head is implemented as a 
> property instead of a ref-returning function or a field, I can't swap 
> the heads of two ranges!! This limits how ranges can be implemented; I 
> was hoping to allow head as a property, but it looks like I can't. Same 
> goes about opIndex. If you define a random-access range, you can't 
> define opIndex and opIndexAssign. You must define opIndex to return a 
> reference. That's a bummer.

Yuck.

> 
> 
> Andrei