On 01/07/12 04:00, Walter Bright wrote:
On 6/30/2012 6:05 PM, bearophile wrote:
Walter Bright:
It's not a bug. It's deliberate, and is there to support mechanical
translation of Java code.
Is this stuff written somewhere in a D design rationales page?
Now that D is several years old, how much Java code was ported to D?
(Despite
there is no mechanical Java->D translator yet).
Yes, a mechanical translator was used extensively to create dwt.
Was this automatic translation
desire worth the troubles (like inner classes,
Yes.
like the risk of killing switch optimizations by mistake)?
Calling it a "risk" and "killing" is way, way overstating things.
This post is about two Scala annotations. If that's not a bug, is
something like
that first Scala annotation useful in D too?
I don't really see any problem requiring a solution. If you're working
on optimizations at that level, you ought to be comfortable examining
the asm output for that and all the other stuff, too. Setting a store on
just one aspect of switch implementations is a large mistake.
The problem isn't the effect on optimization. The problem is that the
semantics are insane. They are like nothing else in the language, and
they don't make any sense. It's a very complicated feature: eg what
happens if the case is a shared variable? Under what circumstances is a
symbol treated as a variable, rather than a constant?
As far as I know, no other language works anything like this. Either
switch accepts only constants, or it accepts arbitrary expressions. Not
this bizarre combination of both.
Do you have a reference for this Java behaviour? I did a quick google,
and everything I found indicates that case labels must be constants.
