Revised RFC on range design for D2

[Sergey Gromov]

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