DIP23 Counter Proposal

[Andrei Alexandrescu]

On 2/6/13 12:41 PM, Timon Gehr wrote:
>> 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 (!).
>>
>
> They are neither. They are just insignificant information thrown away by
> the parser.

Nononono. Hold them horses. We can't gloss over things like that. That 
means in this context parens don't have the usual meaning of expression 
grouping, because what's inside is not an expression. They are 
punctuation that makes &((...(symbol)...)) one syntactic unit identical 
to &symbol.

>> 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.
>
> Ah, very good point! But please note that this is 100% a ternary
> operator issue.

Not at all. What do these mean?

&({ return fun; }())
&(fun, fun)

The last one is really fun because the same thing may be evaluated first 
and then have its address taken. Wow. But of course it doesn't. Why? 
Because "&" and parens have special meaning for &(fun), which is my point.

>> 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.
>
> 1. There is no point where the DIP calls "&" an "operator".

It doesn't have to. It's everywhere else in the language. That's my 
point: new meaning of "&".

> 2. It succeeds in keeping parens mean grouping. (Given any of the two
> behaviours of ternary expressions.)
>
> DIP24 meets its own definition of success.

Of course, if moving the goalposts is an option. My understanding was 
that the express purpose of DIP24 was to avoid potential confusion and 
avoid ascribing new meaning to "&" or parens. As far as I can tell it 
failed at both: "&" is sometimes not an operator, and parens sometimes 
don't encompass expressions.

>> In my opinion, it also makes DIP24 fail to improve over DIP23.
>> ...
>
> In my opinion too. It conveniently also makes all other statements true,
> as the line of reasoning crucially depends on fallaciously ascribing
> properties of the ternary operator to the parens enclosing it.

That got destroyed above.

> (The second fallacy is ascribing the properties of rvalue vs. lvalue
> distinction inherited from C to DIP24.)
>
>> 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.
>
> That is inaccurate, and it is special enough that I do not care to fully
> formalize the special meaning ascribed to parentheses by DIP23.

DIP23 does not ascribe any special meaning to parentheses. That's 
actually part of the point and a good thing about it. I think there's a 
misunderstanding somewhere.

> Basically it makes use of parens affect whether some position in the
> syntax tree is treated as lvalue or rvalue position in some special cases.

No, that is incorrect.

>> If DIP25 gets approved, taking the address of ref results will be
>> banned, and therefore that potential meaning of "&" disappears, which
>> simplifies things.
>
> How? It only adds code to my front-end to make sure the case is actually
> caught and properly reported. It does not even simplify the byte code
> compiler. (Because it uses similar code paths for the &foo() and
> foo()=exp cases.)

I think DIP24 means more code to the front end, more special rules, more 
explaining, and more confusion than DIP23.

>> But we'll still have to live with the reality that in
>> the constructs "&foo" and "&expr.foo", "&" is not an operator.
>
> As well as in all other constructs where it is used in unary form.
>
>> And that's okay.
>>
>
> Except for the unfortunate confusion it can cause.

And that DIP24 does not get rid of.


Andrei