Fixing D's Properties

[Bill Baxter]

BCS wrote:
> Reply to Chad,

> The basis of your thoughts seem to come from the idea that hiding the 
> fact that properties are functions would be a good thing. I would assert 
> that this is highly debatable.

Ah yes.  Although I generally agree with Chad, you did remind me of 
something.  In my Luigi GUI library I use properties for lots of widget 
settings (things like a button's label, etc), and also rely on being 
able to call those as delegates for signal-slot connections to set the 
properties.

That's handy, but it only works for members/properties that are written 
as functions.  What I should probably do is to auto-generate a delegate 
wrapper for pure data members if you try to use one as a slot for a 
delegate(T setval) type of signal.

The other issue it runs into is the overload ambiguity of
    void foo(int) {}
    int foo() {}
when you take the function reference.

One way to resolve the desire to use properties, not pretend they're 
functions, and still allow usage as a function when possible, would be 
to allow giving the functions names different from the property name.

So then you could do something like:

    void set_foo(int) {...}
    int get_foo() {...}
    property foo(get_foo,set_foo);

Or
    property foo {
      void set_foo(int) {...}
      int get_foo() {...}
    }

Of course now you can already make aliases if you just want unambiguous 
function names to take the address of.  (Doesn't prevent using foo() as 
a function though)
    void set_foo(int) {...}
    int get_foo() {...}
    alias set_foo foo;
    alias get_foo foo;  // not 100% sure this works...

--bb