DIP23 draft: Fixing properties redux

[Timon Gehr]

On 02/04/2013 06:36 AM, Andrei Alexandrescu wrote:
> On 2/3/13 11:31 PM, Jonathan M Davis wrote:
>> I tend to agree that making the parens change the nature of the
>> expression is a bad idea.
>
> I think there's some misunderstanding here.

Agreed.

> Parens change the nature of expressions ALL the time.
>

In D? No way.

Precedence rules are introduced in order to make parens _implicit_.

In a language with unary & and binary ., There are two possible 
interpretations for &a.b:

(&a).b
&(a.b)

In the case of D, &a.b is just a shortcut for &(a.b). How can they 
denote different things?

> There is a weird rule in C++11 that makes sometimes typeof(expr) and
> typeof((expr)) mean different things.

There is also the argument-dependent name lookup thing

namespace bar{
     struct S{} baz;
     S foo(S x){ return x; }
}

int main(){
     foo(bar::baz); // Koenig lookup finds bar::foo
     (foo)(bar::baz); // no Koenig lookup, foo undefined
}

Not examples to follow.

> That is arguably an example to
> avoid. But introducing parens among parts of an expression is expected
> to affect meaning.
>

Sure, but that is not what happens here at all. The parens are 
introduced around ONE part of the expression.