[phobos] Time to get ready for the next release

[Robert Jacques]

On Sun, 24 Apr 2011 07:29:22 -0400, Jacob Carlborg <doob at me.com> wrote:
> On 24 apr 2011, at 01:27, Jonathan M Davis wrote:
>
>>> 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.
>
> I'm pretty sure it doesn't do any property rewriting. There's also this  
> problem (that also C# has) that also has been discussed before:
>
> foo.bar.value = 3;
>
> "foo" is a struct or an object. "bar" is a getter property which returns  
> an object and "value" is setter property that sets a value. If you have  
> some kind validation in a "bar" setter property it will be bypassed.  
> This can be fixed with property rewriting. BTW, I pretty sure there's an  
> issue in bugzilla about this.

Yes, there is a a bug about it, but it doesn't occur when 'bar' is an  
object/ref T, it occurs when 'bar' is a struct/value type. It happens  
because 'a.b.c = 5' gets rewritten into 'auto temp = a.b; temp.c = 5;' If  
b/temp is a reference type, then that store is meaningful. However, if  
b/temp is a struct/value type, then assignment is made to a local copy and  
is lost. I believe the proposed fix would is: 'a.b.c = 5' => 'auto t =  
a.b; t.c = 5; a.b = t;', with greater number of temporaries as the number  
of references lengthens.

>> 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.
>
> Can't that be a requirement, to have a getter, to be able to do chained  
> assignment. How often do you actually provide only a setter without a  
> getter?

I've written and used setters that don't have a getter before, but they  
are not a common use case. But I don't believe you could have such a  
method be anything other than the last one in the chain. i.e. given 'a.b.c  
= 5', c doesn't need to have a getter, but b definitely does. (Also,  
'a.b.c += 5' would require c to have a getter)