Revised RFC on range design for D2

[Andrei Alexandrescu]

Sergey Gromov wrote:
> Sun, 28 Sep 2008 22:53:13 -0500,
> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> The rule is trivial, you may say.  But how about co-variant return
>>> types?  If FooSub is a subclass of Foo, then is it ok for the getter
>>> to return one and setter to take the other?  Or vice versa?  Or how
>>> about implicit conversions.  If my getter takes a long, but my setter
>>> returns an int, is that ok?  How do const variations fit in?  Probably
>>> there's a way to fit those all neatly in an automatic rule (or just
>>> disallow them), but it just makes the rule longer and even harder to
>>> keep in mind (or cuts off functionality people may need).
>> Yah, I was thinking of all these and then some more while I was posting.
>>
>> I think it's another duck typing thing. If you can call:
>>
>> entity.prop(entity.prop);
>>
>> then you can consider prop a property, period. Entity could be anything 
>> that allows the dot member access (object, class, struct, union, 
>> template, or module). Given that there is no global scope in D, that 
>> takes care of everything. I think it's really hard to get any simpler 
>> than that.
> 
> D has a simple rule for property methods.  This rule has side effects.  
> If the side effects are so bad that a hack is required to counter them,
> then the rule should be replaced with a better one.  Otherwise your hack 
> will inevitably introduce new, less obvious side effects than those it 
> were supposed to fight, and will finally require other hacks.
> 
> struct Range
> {
>   ref int head() {...}
> }
> Range r;
> r.head = 5; // error

A function can return an object that allows assignment even today with 
opAssign.

I said "If you can call: entity.prop(entity.prop); then you can consider 
prop a property, period." I did not say "If and only if".


Andrei