The type within a generic method can't be statically known. Consider a generic library method that creates an array somewhere deep in its internals, and is called from an application compiled separately.
Now of course you can say that library method requires some extra information from its caller - but how do you reflect that in the method signature in such a way that the binary compatibility constraints are clear and it remains intelligible what the signature is when invoking that method from Java?
If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?). If you want to specialise object arrays to primitive arrays for efficiency, then I do not see why this cannot be a compiler optimization, since the types are statically known at the use sites.
Perhaps Java interoperability is the reason for the choices Scala made, but it doesn't appear that e.g. Scala collections can be used from Java?
> If it creates a specialised concrete array at runtime, then it can't be a truly "generic" method (whereby I assume generic here means parametric polymorphism?).
I'd argue it is, because the semantics of an array are the same whatever that array contains. In any case, there's no nice alternatives: a lot of Java APIs use Arrays, so not being able to work with them would be unpleasant, while having contexts in which you could work with existing arrays but not instantiate new ones would be weird and not a good fit for an immutability-oriented language like Scala (it would match what Java does, but Java is a lot more mutation-oriented).
> not see why this cannot be a compiler optimization, since the types are statically known at the use sites.
The use site for the generics could be arbitrarily many compilation units away from the code that instantiates the array. If it were just primitives then we could use @specialized and generate multiple copies, sure, the issue is that Java arrays are unboxed for any type including custom ones.
> Perhaps Java interoperability is the reason for the choices Scala made, but it doesn't appear that e.g. Scala collections can be used from Java?
They can be used, though in practice it's cumbersome enough that you probably wouldn't want to. The current collections API was created after Scala was relatively well-established and so had different priorities from early language design.
Now of course you can say that library method requires some extra information from its caller - but how do you reflect that in the method signature in such a way that the binary compatibility constraints are clear and it remains intelligible what the signature is when invoking that method from Java?