On 02/07/12 23:20, Walter Bright wrote:
On 7/2/2012 1:04 PM, bearophile wrote:
Walter Bright:
Put "final" in front of y, and it will compile. Remember, this was
done for D1
that didn't have const.
I see. So in D2 are we going to require that y to be immutable?
No. I don't agree there's a problem. Nor do I care to break existing D1
code (and D2 for that matter) without an awfully good reason, and I
don't see one here.
This behaviour is *not* currently in the spec.
And if you give any other kind of runtime expression, you get an error
message which suggests it shouldn't work:
void main()
{
int x;
int y;
switch(x)
{
case *&y: break;
}
}
bug.d(10): Error: case must be a string or an integral constant, not *&y
----------
It would be really difficult to define the current behaviour. I don't
understand it. Let me explain how bizarre it is.
What it does is, run optimize(WANTvar) on the expression. If at the end
of optimization, it is a VarExp of type integer or class, then it can be
a run-time value. It must be a VarExp, it cannot be a DotVar.
Now, what does optimize(WANTvar) actually do? Under what circumstances
can it produce a VarExp? I'm not sure. You really need to check every
code path in optimize.c and constfold.c.
It can happen with comma expressions, for example.
So this:
case 7+8, y:
is accepted.
Are there circumstances where X.Y can be accepted? Maybe some
combination involving alias this or opDispatch ? I don't know.
