Revised RFC on range design for D2

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Mon, Sep 29, 2008 at 8:32 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Andrei Alexandrescu wrote:
>>> How about this. Maybe if we attacked this annoyance in particular, that
>>> would be a large bang for the buck without a landslide change in the
>>> compiler. We only need some way to inform the compiler, "yes, it's ok to
>>> call a.b(c) as a.b = c". Ideas?
>> I actually did have something in mind when I wrote this, just didn't want to
>> bias anyone.
>>
>> My thinking is that the syntax "a.b = c" in lieu of a.b(c) for a function
>> a.b(T x) should be allowed if and only if there also exists a function a.b()
>> that returns a value of type T.
>>
>> Example:
>>
>> struct S1
>> {
>>    void prop(int x);
>> }
>>
>> S1 s1;
>> s1 = x; // error, prop is not a property
>>
>> struct S2
>> {
>>    void prop(int x);
>>    int prop();
>> }
>>
>> S2 s2;
>> s2.prop = 42; // fine, prop is a property because it also has a getter
>>
>> This solution does not require any syntactic addition. Its drawback is that
>> it makes it hard to define write-only properties. Are they important?
> 
> Seems a little too subtle to me.  Maybe no problem for the compiler,
> but yet another kooky rule the human has to hold in their brain when
> trying to read D code.
> 
> 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.

> Also how about preventing the calling of property setters as functions?
> 
> s2.next(42) looks like it will do something quite different from
> s2.next = 42.  I would like for property syntax to also disallow
> function call syntax.

I'd also like plenty many things, but they cost.

> ---
> Somewhat unrelated, but there still exists the annoyance in D that if
> you have to functions with the same name and you want to take the
> address of one of them, you can't.  Furthermore I can't think of a
> reasonable syntax to do that easily.  For that reason,  I really think
> the best getter and setter functionality in D would be something where
> you have distinctly named *functions* getProp and setProp for when you
> want/need functions mirroring samely-named *properties* for which only
> property syntax would work.
> 
> Basically there's no convenient way to take the address of one of a
> getter/setter function pair, currently.  I think that should factor in
> the solution here.

Overloading is the issue, and that's quite a different story. If you 
know the exact type, you can take the address of something.

struct S
{
     int foo() {}
     void foo(int) {}
}

void main()
{
     S s;
     void delegate(int) x = &s.foo;
     int delegate() y = &s.foo;
}


Andrei