[phobos] Time to get ready for the next release

[Robert Jacques]

On Thu, 21 Apr 2011 20:14:22 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

>> On Thu, 21 Apr 2011 18:28:10 -0400, Jonathan M Davis  
>> <jmdavisProg at gmx.com>
>>
>> wrote:
>> >> On Thu, 21 Apr 2011 17:17:33 -0400, Jonathan M Davis
>> >> <jmdavisProg at gmx.com>
>> >>
>> >> wrote:
>> >> >> On Thu, 21 Apr 2011 16:14:22 -0400, Jonathan M Davis
>> >> >> <jmdavisProg at gmx.com>
>> >> >>
>> >> >> wrote:
>> >> >> >> On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis
>> >> >> >> <jmdavisProg at gmx.com>
>> >> >> >>
>> >> >> >> wrote:
>> >> >> >> >> How about the amount of existing code it breaks? How about  
>> the
>> >> >>
>> >> >> fact
>> >> >>
>> >> >> >> >> that
>> >> >> >> >> it breaks using the same function for both method chaining  
>> and
>> >> >>
>> >> >> with
>> >> >>
>> >> >> >> >> property syntax?
>> >> >> >> >
>> >> >> >> > Something like
>> >> >> >> >
>> >> >> >> > auto b = a.prop1.prop2.prop3;
>> >> >> >> >
>> >> >> >> > should work. I doesn't at present, but it should. There's a  
>> bug
>> >> >>
>> >> >> report
>> >> >>
>> >> >> >> > on it.
>> >> >> >>
>> >> >> >> What about auto b = a.prop1(5).prop2(6).prop3(7); ?
>> >> >> >
>> >> >> > I'd consider that to be the same. It should work, but it  
>> doesn't.
>> >> >> > There's a
>> >> >> > bug report for it.
>> >> >>
>> >> >> Ahem, so you'd consider auto b = a.prop1(7); valid code under  
>> strict
>> >> >> property rules?
>> >> >
>> >> > Oh wait. You're right. I didn't read that right. No, that wouldn't  
>> be
>> >> > legal.
>> >> > That would be both getting and setting. Why would you even try and  
>> do
>> >> > that
>> >> > with a property, let alone with several chained together?
>> >> >
>> >> > - Jonathan M Davis
>> >>
>> >> First, remember that basic assignments can be chained: x = y = 1; So  
>> a
>> >> property should never return void, whether it's a setter or a getter
>> >> logically.
>> >
>> > 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.
>>
>> But that would be changing the fundamental meaning of the expression  
>> from
>>
>> x = y = 1;
>>
>> to
>>
>> x = y, y = 1;
>
> Why? It should be
>
> y = 1;
> x = y;
>
> Assignment is done from right to left, not left to right.
>
> x = y = 1;
>
> should have identical semantics to
>
> y = 1;
> x = y;
>
> It's true that in the case of an overloaded opAssign, it might not, but  
> when
> it's not, it's pretty much guranteed to be a bug unless the programmer is
> trying to do something weird, which would almost certainly be an abuse of
> overloaded operators. So,
>
> auto b = a.prop1 = 3;
>
> should translate to
>
> a.prop1 = 3;
> auto b = a.prop1;

Well, so long as it's valid to override opAssign's return value,  
properties shouldn't use their own semantics. Then again, fixing  
assignment semantics might be a good idea.