Revised RFC on range design for D2

Bill Baxter wbaxter at gmail.com
Sun Sep 28 20:06:33 PDT 2008


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).

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.

---
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.

--bb


More information about the Digitalmars-d-announce mailing list