if all your fields are of the same type, you can make an array of that type
if they're different types, you can make multiple arrays
I've tried the multiple array approach. Code quickly got seriously hard to make readable and in the end I gave up. Also tried a flyweight "cursor" type approach where the trait was implemented on top of a primitive array with behind the scenes type castes to primitive fields. But likewise it got too complicated. By "elsewhere" I meant another language. My colleague's been learning Rust but I didn't want to commit to a different language unnecessarily.
I wanted to try the following:
import compiletime._
opaque type Positive = Int
object Positive {
inline def apply[T <: Int](value : T) : Positive = {
inline if (value <= 0) error(code"failed on: $value")
else value
}
}
val eight = Positive(8)
val negError = Positive(-1)
but if @jeremyrsmith's is the motivation (and it makes sense to me), it shouldn't be an "Implementation restriction" — that's a conceptual limitation, since inline in Dotty is designed to preserve typability IIRC
If that were allowed, the compiler would have to generate additional (unsafe) casts when inlining.
so I guess you can define an inline
apply outside of the scope of Positive, with the unsafe casts.
If that’s what you want, in principle I agree that could be automated, but it doesn’t sound easy: it seems you’d need to replicate (a variant of) erasure during inlining. Except you’d need to produce casts that appease Scala’s typechecking.
now, the result of inlining doesn’t typecheck, does it?
however, in Dotty the result of each phase must typecheck, and that’s enforced by
-Ycheck (unlike Scalac).
Anyway, I can see why you'd want this to be supported anyway, if you need to use dotty inlining for some reason (say performance, tho it seems JIT should handle this example). Feel free to make a feature request (not that I have a real say), it could well be much easier than I think.
I dunno, I think source-level inlining of that particular case might be unnecessary if it’s intended as an optimization. It would be interesting to see a benchmark though. Since
apply ought to end up as a very small static method over primitive ints, it seems like a rare case when the JVM shouldn’t have any trouble inlining that at runtime
I get that “the JVM will handle it!” is an oft-overused mantra though :grinning:
Since the problems are usually with higher-order functions, maybe fold would be a better example. But I think you need an inner loop inside the fold to see the problem (like with map), so I still can't easily construct a realistic example.
@deusaquilus I think it's similar to plain def and val, in a way. val is evaluated once and stored, so inline val has to be able to pretend this at compile time. So, any code that does ... anything, really, does not work as the only way you can inline something while pretending it was only evaluated once is to know that it's some kind of constant. The current limitation is constant values as defined here: https://www.scala-lang.org/files/archive/spec/2.12/06-expressions.html#constant-expressions (link lifted from Dotty docs). def on the other hand is evaluated on demand. This means it doesn't really matter what the body of an inline def does since the compiler can just paste that code at the callsite and have the result act similar to a def call.
That's my intuition, anyway.
Checking for certainty: With the new
@main method model, there's no way to create a trait or class that will provide a main method to any object that extends it, since the compiler will not allow the @main annotation on non-statically-callable methods (even if a static instance of the class would cause the method to be available statically). Is that correct, or is there a technique that I've missed that could do this?
docs are clear they're not somehow deprecated
Don't think there's an issue
(if I just
publishLocal and change the sbt project to use the snapshot version, it expects dotty-sbt-bridge to be published with the -nonbootstrapped version suffix.)
I really should just rewire publishLocal to do that by default
But publishing the non-bootstrapped compiler isn't really useful so that never did anything usable
