On Thu, 21 Apr 2011 18:28:10 -0400, Jonathan M Davis
<[email protected]>
wrote:
>> On Thu, 21 Apr 2011 17:17:33 -0400, Jonathan M Davis
>> <[email protected]>
>>
>> wrote:
>> >> On Thu, 21 Apr 2011 16:14:22 -0400, Jonathan M Davis
>> >> <[email protected]>
>> >>
>> >> wrote:
>> >> >> On Thu, 21 Apr 2011 15:57:57 -0400, Jonathan M Davis
>> >> >> <[email protected]>
>> >> >>
>> >> >> 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;
