DIP23 Counter Proposal

[Andrei Alexandrescu]

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