Two Scala annotations

[Don Clugston]

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.