Properties: a.b.c = 3

[Ary Borenszweig]

Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Wed, Jul 29, 2009 at 10:50 AM, Andrei
>> Alexandrescu<SeeWebsiteForEmail at erdani.org> wrote:
>>> Bill Baxter wrote:
>>>> Yeh, I don't understand how any of this has anything to do with
>>>> properties.  It's the same question if you ask what should
>>>>
>>>>  a.b().c = 5
>>>>
>>>>  do.  It's the same issue whether you have properties or not, and
>>>> needs a solution whether you have properties or not.
>>> Well the problem is that a.b().c = 5 makes it clear that there's a 
>>> function
>>> call in the mix, so the field-like behavior is not necessarily to be
>>> expected.
>>>
>>> One great thing about properties is that they are mostly interchangeable
>>> with fields. The a.b.c = 3 problem works against that.
>>
>> Maybe you were expecting it to be possible to make properties
>> completely indistinguishable from fields?
> 
> Not quite. If they were completelty indistinguishable from fields, 
> they'd be fields.
> 
>> But that can't really be
>> when you can take the address of a field and not a property.
> 
> Correct. Probably there are other issues as well.
> 
>> The goal
>> has to be removing as many differences in behavior as possible.
> 
> Yah, but that's a bit vague. The a.b.c=3 problem is that a code that 
> looks the same with fields or properties does very different things, and 
> useless under certain conditions.
> 
>> On the point above,  a.b.c = 5 is dicey whether b is obviously a
>> function call or not, if what b returns is not an lvalue.  If I think
>> a.b() is returning a ref and it doesn't, then I want the compiler to
>> tell me I'm doing something silly -- if it can determine so.
>> Properties or no properties.
> 
> Yah. That is by the way a wart inherited from C++. It's one of the few 
> places where you can reach the address of an rvalue: you call a function 
> returning an rvalue and then you call a member function of the rvalue. 
> Inside that member function, there's no knowledge that the object is an 
> rvalue.
> 
> I strongly disliked that behavior of C++, and I dislike it as strongly 
> for D. However, there are cases in which it *does* make sense to call a 
> member function against an rvalue. But those are few and far apart, so 
> I'd like us to look into disallowing member function calls against 
> structs in all situation. That would rid us of this problem and many 
> others.

I don't know why you keep discussing this if C# already implements it 
correctly and nobody has problems with it. Can't D just copy the idea 
and that's it? *It works.*

C# allows you to invoke methods on returned structs. If that method 
modifies the struct itself, then doing something like:

bar.Foo.Method(); // Method does this.Property = 30;

then when you do:

int x = bar.Foo.Property;

x won't have the value 30.

So I think D should also forbid invoking methods on returned structs. 
You can always assign Foo to a temporary and work from it.