4 ms·

Type inference isn't about reading or writing code. It's about proving that the code is correct with respect to the language semantics: type inference and chec

Type inference isn't about reading or writing code. It's about proving that the code is correct with respect to the language semantics: type inference and checking are relatively lightweight forms of code verification. If you have code that works and passes the type checker, and upon modification fails the type checker, that often reveals issues about how that code composes with code that calls it. That isn't "blocking" you from modifying the internals of a function: if those modifications cause the type checker to fail, you've likely got a problem with how that function is used. It isn't trying to make your life difficult - it's telling you that assumptions you may have made about your code in isolation are not valid assumptions when considering how that code you're working on interacts with other code that you aren't focused on. Type inference isn't an IDE feature related to autocompletion. If that's how you perceive it, you might benefit from learning what type inference is about and what role it plays in the development process.

dllthomas 4y ago
> Type inference isn't an IDE feature related to autocompletion. Except... it sorta is? The benefits you describe are real, but they are derived from type checking. In principle you can get the same effect while making all the types explicit. Without basic type propagation this is horrifically verbose to the point that no language I'm aware of rolls that way. Without type inference, it's usually manageable. Type inference is a (very!) nice to have feature on top of that where the compiler is kind enough to fill in the details it can figure out, which doesn't happen to live in the IDE (usually? ever?) but is basically the same idea as IDE autocompletion except that the result is not typically visibly reified (... outside of an IDE or equivalent). What I disagree with from the grandparent is the notion that the type annotations (that inference allows us to remove) always or overwhelmingly improve readability. I think the verbosity they add - particularly when they get repetitive - means they often obscure far more than they enlighten. And when they do pay their way - which is not rare - you are still free to include the annotation!

dllthomas 4y ago

> Type inference isn't an IDE feature related to autocompletion. Except... it sorta is? The benefits you describe are real, but they are derived from type checking. In principle you can get the same effect while making all the types explicit. Without basic type propagation this is horrifically verbose to the point that no language I'm aware of rolls that way. Without type inference, it's usually manageable. Type inference is a (very!) nice to have feature on top of that where the compiler is kind enough to fill in the details it can figure out, which doesn't happen to live in the IDE (usually? ever?) but is basically the same idea as IDE autocompletion except that the result is not typically visibly reified (... outside of an IDE or equivalent). What I disagree with from the grandparent is the notion that the type annotations (that inference allows us to remove) always or overwhelmingly improve readability. I think the verbosity they add - particularly when they get repetitive - means they often obscure far more than they enlighten. And when they do pay their way - which is not rare - you are still free to include the annotation!