Possible @property compromise

[Steven Schveighoffer]

@property has gotten a lot of flak lately, and I think the unenthusiastic  
implementation of it really hasn't helped.

BUT... there are a few problems with the original non- at property  
implementation that are fixed by having additional syntax (well, if it was  
properly implemented):

1. Treating any old function as a setter.  This is the writeln = "hi"; mess
2. Forcing you to use 2 sets of parentheses when returning a callable type.

However, we have seen the addition of two problems with @property.  First  
is when UFCS was introduced.

@property int iprop(int val) {...}

can be called as:

52.iprop;

or

iprop = 52;

Second problem is, when ref returns are used on properties:

@property ref int iprop();

auto x = &iprop;

Should x be the delegate for iprop, or call iprop and get the address of  
the return value?

ASIDE from the disdain that many developers have towards @property, I  
think above anything else, that the first problem @property fixed above is  
essential to the freedom of naming functions for API designers.  The  
second problem of getting delegates via properties is fixed,  so it would  
be a step backwards if we just removed @property.

So in light of all that, I propose a compromise:

1. Deprecate @property.
2. When the compiler encounters a field setting like this:

x.y = ...;

If a y field exists on the aggregate represented by x, then that is the  
assumed member being referenced, and compilation continues normally.

If there is no y field, then then the compiler ALSO tries:

x.setY(...);

It is important to note that:

x.y(...);

does not compile, y is not just another function.  To call in function  
form, you must call:

x.setY(...);

That takes care of setters, AND takes care of the new problems with  
@property.

3. Parentheses remain optional on functions, allowing the creation of  
getters as before @property.

However, this does not fix the delegate problem.  To fix that problem, we  
can use the complementary getY to allow specifying a getter that does not  
absorb parentheses.

One problem I will note with this scheme, some Unicode symbols that may be  
valid D symbol starters may NOT have an upper/lower case, making it  
impossible to use those as properties.  But I admit having an English bias  
so I don't see this as a large problem.  Besides, "set" is already English.

Note, I've been doing a lot of Objective C lately, and I kind of like the  
property scheme there (this is quite similar).

Sound crazy?  Ridiculous?  Impossible?  Insulting?

What do you think?

-Steve