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.
