Proposal request: explicit propreties

[Bill Baxter]

Ary Borenszweig wrote:
> Currently properties can have these forms:
> 
> Getter:
> -------
> Type property() {
>   // ...
> }
> 
> Setter:
> -------
> void property(Type type) {
>   // ...
> }
> 
> The problem is, the user can use them as functions or as properties. 
> This is ok from the compiler point of view, but the code looks ugly if 
> it doesn't make sense, like:
> 
> writefln = 5;

I'm vaguely for designating properties as such, like you suggest, but I 
have some reservations:

Nobody would write code like writefln=5, but I have seen code that used 
this:

    writefln;

Is that so wrong? Anyway, some people seem to think that's a nice way to 
write zero-arg function calls.

I've also run across cases where the compiler fails to realize it should 
call a property method unless you explicitly put the () after it.  I 
can't recall exactly where.  That's just a bug, but it is something to 
consider.

Finally, getters and setters are prime targets for signal/slot 
callbacks.  So I would hope that despite .foo(5) being invalid, that you 
could still take the address of the property setter method to pass it to 
a callback setter.  But I guess that kind of defeats the purpose.  Hmm. 
  Maybe this works?:
      setCallback( (int x) { myFoo.prop = x; } )
I guess that works in D2 with it's full closures, but not D1 because the 
myFoo will go out of scope.  But still it seems unsatisfying to heap 
allocate an extra closure there, when .prop is actually a function to 
begin with.

On the other hand, taking addresses of an overloaded method is a 
hit-or-miss situation right now anyway, so maybe it's a good idea to use 
the lambda anyway (in D2).

--bb