On 2/5/13 7:39 PM, Timon Gehr wrote:
As my posts in the DIP23 thread have been left unanswered, I have
prepared a counter proposal for DIP23 during the last hour.
Everything DIP23 addresses is specified in the two short sub-sections
"Optional parens" and "@property: basic design".
Those in favour of what was called "semantic rewrites" in the DIP23
thread should probably read on further.
All parts of this proposal are independent of DIP24 (which Andrei is
preparing).
http://wiki.dlang.org/DIP23_Counter_Proposal
There are almost no examples yet, but in case it is not clear how some
case would be handled, feel free to ask.
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.
There's also "(Note that redundant parentheses are assumed to be dropped
in the parsing stage.)" It's unclear whether this makes &(foo) and
&(((foo))) identical to &foo. If they don't, then "&" is not an operator
in the expression "&foo" because an operator should be applicable to a
parenthesized expression. If they do, in this context parens are also
punctuation, not expression grouping; they don't enclose an expression,
but instead define &(((...(foo)...))) as a sole syntactic unit (!).
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.
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 should point out that that's all okay, but we got to be clear about
it. Tokens are used as both punctuation and operators all the time. For
example, it may sound weird that (stuff) and ((stuff)) should ever mean
distinct things, but writeln((1, 2)) does something different from
writeln(1, 2). This is because the outer layer is punctuation and the
inner layer is expression grouping. And nobody blinks an eye. The
language just needs to be as clear as possible about which is which.
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.
Andrei
