Hello everyone,
I’ve written a draft SIP on inline and specialized traits for compile-time specialization. This would reintroduce a desirable feature from Scala 2 that has been missing in Scala 3.
Constructive feedback would be greatly appreciated.
8 Likes
Can anyone remind me why this wasn’t carried over from Scala 2?
I remember there being a reason but it’s not listed in the dropped features in the Scala 3 docs so I don’t recall.
If I had to guess the reasoning, it was mostly code bloat - compile time specialization explodes the amount of bytecode generated and god forbid you have 2 (or more!) specialized parameters.
A good example of how this can end up exploding is fastutil. It’s written using Java auto generation jank but you can see just how obscene the number of classes even in a single package is.
I think we shouldn’t put this feature in Scala, especially if in the future it will end up being replaced by JVM features and optimizations. There are historical attempts to do specialization at runtime and more recent (if you consider 2020 recent) attempts as well.
In my view we should not be adding features the JVM will replace because that will lead to ugly warts. A good example is the early Scala 3 lazy val code - it used com.misc.Unsafe and that’s terminally deprecated now, so any Scala 3 app using an pre-3.8 scala library will get messages from those lazy vals.
Of course downstream Scala native could possibly benefit from this, but any work there probably shouldn’t be cross target.
2 Likes
Reasoning is given in the motivation section of this SIP.
I don’t have proofs these were the original reasons, but they seem compelling enough
(Maybe @odersky can give some historical insights)
This is one of the given reasons in the motivation section
The proposal is built around answering this concern
I agree in theory, but we don’t know what features the JVM will have in the future !
Even where there are attempts, it’s hard to know whether they will pan out, and what shape the final product will have, and it’s not always possible to wait
1 Like
weird timing, given that initial parts of project valhalla were recently integrated (as a preview feature) into mainline java: JEP 401: Value Objects (Preview) and that suggests the overall design is stable enough for java authors to progress with implementation of more parts of project valhalla.
iirc, years ago there was an effort to make scala linker, which could theoretically do the specialization only for generic parameter combinations that are used in a given project. that would make it similar to c++, iiuc. it would make a lot of sense especially now, as we have scala-native, scala.js and scala-wasm, which all have linking as final step.
scala-on-jvm would get solid generic specialization boost from future project valhalla parts, like probably JEP 218: Generics over Primitive Types (or some iteration of that jep). efforts in jvm area combine java’s laziness (individual *.class objects can be compiled and loaded whenever needed, there’s no single big bang compilation or linking phase needed) with strong jit optimizations.
rebooting compile-time specialization, that is just some enhanced form of what scala 2 had, feels like some unsatisfactory stopgap solution, unless there’s a plan to extend it to a full linker with full monomorphisation (so it would reduce the performance and efficiency gap between future scala-on-jvm and scala-on-non-jvm).
1 Like