DIP23 draft: Fixing properties redux

[Timon Gehr]

On 02/04/2013 03:28 AM, deadalnix wrote:
> 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.
>

It is not even made complex. It is quite obvious how things should work. 
(and &a vs &(a) is not it.)

> We are trying to make @properties behave like fields,

(Syntactically.)

> but hey in this  case I want it to behave like a function . . .

This is the step that must be reconsidered.

> 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).
>

Certainly not! & is the syntactic element distinguishing functions from 
return values, not (). Optional & would be about conflating the function 
with its return value. (Scala basically does this, but instead of prefix 
& they use suffix _.)

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

Most of this stuff is simple enough. Have you implemented optional 
parens already?