DIP23 Counter Proposal

[deadalnix]

On Wednesday, 6 February 2013 at 15:32:33 UTC, Andrei 
Alexandrescu wrote:
> So syntactic case (2) prescribes that when foo is in 
> address-taken position "&foo", that means take its address as 
> opposed to evaluate foo. That makes the use of "&" here sheer 
> punctuation, as opposed to operator.
>

That is one of the node of the optional () problem. Your DIP have 
similar issue with &.

> This also leads to potential confusion, seeing as &(foo) takes 
> the address of foo, but &( true ? foo : bar ) does, in fact, 
> take the address of whatever foo returns. This makes the role 
> of "&", "(", and ")" in the proposal as both punctuation and 
> operator painfully visible.
>

As ell, your proposal have similar issues.

> This all makes DIP24 fail meet its own definition of success as 
> far as I understand it, i.e. keeping "&" to mean operator and 
> parens to mean grouping. In my opinion, it also makes DIP24 
> fail to improve over DIP23.
>
> DIP23 has in fact /fewer/ such problems, because it clarifies 
> that &foo and &expr.foo are indivisible syntactic units; thus 
> parentheses are not ascribed a special meaning by DIP23. On the 
> contrary, as soon as parens are used, as in &(foo) or &( true ? 
> foo : bar ), the usual meaning of parens enters in action and 
> give the expression inside the usual meaning.
>

I do see special meaning as an issue, as it complexity the 
language. DIP24 is an improvement in that regard over DIP23.

> If DIP25 gets approved, taking the address of ref results will 
> be banned, and therefore that potential meaning of "&" 
> disappears, which simplifies things. But we'll still have to 
> live with the reality that in the constructs "&foo" and 
> "&expr.foo", "&" is not an operator. And that's okay.
>

That is cascading the problem, not solving it.