Properties: a.b.c = 3

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Jul 29 11:18:35 PDT 2009


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.


Andrei



More information about the Digitalmars-d mailing list