Revised RFC on range design for D2

[KennyTM~]

Andrei Alexandrescu wrote:
> 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

Just wondering... What about opCall's? Will it be considered while 
evaluating "entity.prop(entity.prop)"? (I hope not :p, and an object S 
won't be evaluated to S() := S.opCall() anyway.)

struct A {
   invariant void opCall(invariant(A) x) { writeln('hi'); }
}

struct B {
   invariant(A) a;
}

b.a(b.a) compiles but b.a = b.a does not make sense (b.a is not mutable).