DIP23 draft: Fixing properties redux

[deadalnix]

On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
> On Monday, 4 February 2013 at 01:30:49 UTC, Andrei Alexandrescu 
> wrote:
>> I think most, if not all, detailed rules derive from these.
>
> One does not, the strange special case for taking the address 
> of a property.
>
> I'd REALLY urge you to explore alternative solutions, such as 
> the one proposed by Andrej, before introducing an abomination 
> like distinguishing between "&a" and "&(a)".
>
> There is no way such strange behavior could be explained in a 
> way that is coherent with the rest of the language.
>
> I found that when you are working on a complex problem and have 
> a solution that seems to work for everything except a little 
> detail, the best approach often is to step back a bit and have 
> an entirely fresh look at that area again, but now taking the 
> rest of your design as a given.
>

The problem we are dealing with here isn't complex. It is made 
complex artificially.

We are trying to make @properties behave like fields, but hey in 
this case I want it to behave like a function . . . oh yeah so in 
this special case, I have to workaround, ho and here and here as 
well, oh damn, that is complicated.

Same goes when conflating the function with it's return value 
(which optional () is about).

> Introducing a rule by which parenthesizing an expression in a 
> way that does not change precedence suddenly causes a 
> difference in behavior certainly wouldn't be among the first 
> ideas coming to my mind this way.
>

By trying to make things easy, we miss that the important point 
is to make them simple.