suggestion for eliminating the overload ambiguity for properties

[Bill Baxter]

Right now there's a problem in that if one uses property methods as 
suggested by the D reference manual:

class Foo
{
   int prop() { ... }
   int prop(int x) { ... }
}

then you can't reliably get a delegate to the setter.   &aFoo.prop gets 
you whichever appears first, which in this case is the getter.  This is 
a known bug, and the most likely resolution for it will be to make 
trying to do this an error.

So what if we just give D support for Java-style convention-based 
deduction of properties.  You can keep using properties as-is, but _if_ 
there's a method called 'set_prop' then it can be used as a setter 
property.  So the above could be written as:

class Foo
{
   int prop() { ... }
   int set_prop(int x) { ... }
}

This way you can still use your property syntax, but you can also easily 
distinguish the getter from the setter when taking a delegate.

---
Would it be possible to write a __traits-using mixin that scanned the 
class mixed-into for methods of the form "set_blah" and created a simple 
wrappers around them like:
    T blah(T v) { return set_blah(v); }

Can a mixin can add members generated on the fly like that?

--bb