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.
