Possible @property compromise

[q66]

On Tuesday, 29 January 2013 at 17:10:00 UTC, Steven Schveighoffer 
wrote:
> @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(...);
>
no, just no.

> 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.
>
"natural language inspiration" ... hmm .. where have I seen this? 
oh right, let's make a DOBOL.

> 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
more like all four combined.