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
