[phobos] Time to get ready for the next release

[Jonathan M Davis]

> On 22 apr 2011, at 00:28, Jonathan M Davis wrote:
> > Actually, setters _should_ return void. The chaining should be done by
> > calling both the getter and setter functions. The other options is a
> > property function which takes nothing but returns a ref. In either case,
> > the chaining would work.
> 
> Wouldn't this require some form of property rewriting?

Hmmm. Yes it would, which I was thinking was what properties were doing 
anyway, but now that I think on it, I'm not sure they do. The getter certainly 
doesn't, but I don't know about the setter. So, I'm not quite sure what the 
compiler is doing right now, but calling both the getter and setter for 
chained assignment would require a lowering.

Then again, now that I think of it, if you require both the getter and setter 
for chained assignment, chained assignment won't work for write-only 
properties. So, I don't know what the solution should be. It was my 
understanding that a function could _be_ a setter if it returned anything. It 
had to take a single value and return nothing (or take two values where the 
first was an array and you were calling it using the array's member function 
call syntax). And with that being the case, you _must_ use the getter to 
generate chained assignments.

So, now I'm a bit confused on the chained assignment bit. The fact that the 
compiler virtually ignores @property right now makes it much harder to 
determine how it's supposed to work. It was my understanding that

T prop() //getter
void prop(T val) //setter
ref T prop() //both getter and setter

were supposed to be the only valid signatures for getters and setters (save 
for the addition of the array parameter with arrays), and it seems like that's 
not currently true. TDPL is very specific that the syntax is supposed to be 
strictly enforced, but it's not very specific on the correct signatures for 
getters and setters.

So, after this discussion, I'm at least marginally confused. Certainly, a lot 
of what some folks expect of properties comes from what currently works rather 
than what's supposed to work, and what's supposed to work is not always clear 
- at least as far as the exact signatures for getters and setters go.

- Jonathan M Davis