DIP23 draft: Fixing properties redux

[David Nadlinger]

On Monday, 4 February 2013 at 02:28:39 UTC, 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.
>
> 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).

Not sure I'm following – you are arguing that the whole endeavor 
is futile as long as we keep parens-less function calls?

I actually think that DIP23 is a big step in the right direction, 
given that parens-less function calls are *very* unlikely to go 
away. Contrary to some of the previous proposals, it's actually a 
principled approach, like Adam and others (including me) have 
asked for. Now it's just a matter of getting the details right.

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

My point is precisely that. I think there are much simpler 
solutions than adding some magic properties to a pair of 
parentheses in the right position, even if it might look like a 
convenient hack.

David