ref returns and properties

[Andrei Alexandrescu]

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.

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.


Andrei