[phobos] Time to get ready for the next release

[Robert Jacques]

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.

Second, there are situations where you want to be able to support:

a.prop1 =  5;

and

auto b = a.prop1(5).prop2(6);

or simply

a.prop1(5).prop2(6).prop3(7);


syntactically. There's also times/uses for functions to be chained  
together using property syntax i.e.

a.verb1.verb2.verb3.verb4;

instead of

a.verb1().verb2().verb3().verb4();

But that's a slightly different issue.