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