The compiler might [k]now which are needed if you are creating an application, but in case of a library you need all variances.
Well if one were to really implement type signatures with inferencing, one would write out blobs describing them (as type inferencing languages do). That’s how you only instantiate the ones you need. This puts more work on the linker for Java interop, but the theme here is letting the tools do the work and letting the programmer be concise. Note the linker needn’t be aware of kotlin in particular; it just needs to recognize certain blobs describing type-instantiated functions. One could think of it as a future Java feature that only kotlin implements.
If it is non obvious to the programmer what the type is, that is a problem IMO. I just leads to unexpected behavior and bugs.
But the whole point is that the same function in code can return different types. We wish to avoid the busy work mindset of Java – to avoid manually writing out one version which returns float and another which returns double. We wish to avoid overspecifying. The constraints on the type are sufficient – that’s what the programmer needs to pay attention to. The exact type is immaterial to the logic of the code as long as the type constraints are met.
You’re saying that a simple text editor, which supports syntax highlighting at best, can somehow tell you the inferred type of a function, without being considered a full IDE?
I’m saying there typically isn’t an inferred type in the first place, per the design and purpose of the language. For instance, the language was designed so that a function expecting a certain type of object would also accept a mock object having no relation to anything the function has seen before. Being cavalier with types is a feature of that particular language, not a bug. That’s why it’s apples and oranges with respect to kotlin.
There might be some dialects of lisp which are statically typed, but I thought lisp in general does not have static typing so the comparison to lisp is not really relevant in this regard.
Static types may be optionally declared in Common Lisp. SBCL makes use of those declarations for type inferencing. The point here is that if Lisp – where type declarations are optional – can do type inferencing, then kotlin – where types are already known – sure as hell can. The doc I quoted seemed to suggest that inferencing wouldn’t work well for blocks, but that’s just not true. It works well in SBCL, where it’s harder to do.