Function calls

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:hjt449$5d8$1 at digitalmars.com...
> Bill Baxter wrote:
>> On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
>>>
>>> The problem is not localized change. The result of stdin.byLine changes 
>>> the
>>> _entire_ stdin.
>>
>> Ok, so you have no problem with a car.wheels returning a mutable wheels 
>> object?
>> So it's only when the returned property can change the entire state
>> (or a lot of the state?) that you have a problem?
>> I don't understand how degree changes the acceptability.  Doesn't seem
>> like it should matter to me.
>
> If you access car.wheel, it is reasonable to repaint that wheel. The 
> problem is that you can use car.wheel to repaint the car.
>

Ok, so you don't think a property of something should be able to change 
other parts of that something? Ok, I can understand that. But if that's so, 
then how would it be any better to be able to change something through the 
return value of one of that something's member functions? (Which, of course, 
is what stdin.byLine apperently already does.)

Ie, Given this code:

auto foo = stdin.byLine;
foo.doSomethingThatAdvancesStdin();

How is it possible for that code to be bad when "byLine" is defined as a 
"@property", but suddenly be perfectly fine when omittable parens are 
allowed and it's defined without "@property", even though either way it's 
still the exact same code doing exactly the same thing and having exactly 
the same effects?