On 27-05-2012 15:13, bearophile wrote:
I have found two Scala annotations.
1) The first one is @switch:
http://www.scala-lang.org/api/current/scala/annotation/switch.html
Currently this D2 code compiles:
void main() {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
default:
}
}
I think that accepting that "case y" is a compiler bug, because y is a
run-time value, that kills some switch optimization possibilities.
A couple of things here:
1) Any half-decent compiler *will* optimize this thanks to a wide array
of standard dataflow analyses.
2) Even if the compiler couldn't optimize cases like this one, I don't
think it matters. I don't know from where people got this crazy idea
that a switch statement MUST compile to a jump table *no matter what*
(though I suspect C is the cause of this madness). I think it's silly.
Even a lot of the things D's switch allows (range cases, for example)
kill the opportunity to turn it into a jump table. So even if you
disallow this case, it won't really buy you anything. If someone is
aware of the jump table optimization of switch statements, then surely
they know that using a runtime value will kill that optimization. And if
they don't know, it doesn't matter anyway! Worst case, it'll just be
unrolled to what's equivalent to an if/else forest.
Inside D code the presence or absence of an annotation semantically
related to that Scala @switch is able to disallow / allow the presence
of a run-time value among the cases.
------------------
2) The second is @implicitNotFound:
http://www.scala-lang.org/api/current/scala/annotation/implicitNotFound.html
More info:
http://suereth.blogspot.it/2011/03/annotate-your-type-classes.html
Maybe a related idea is able to improve/add error messages when certain
template constraints fail (to be used when you have just 1 template,
where constraints failure means wrong input or something clearly missing
in user code).
Bye,
bearophile
--
Alex Rønne Petersen
[email protected]
http://lycus.org
