Edit: by "screwing up semantics" I mostly mean the combination of overloading and implicit conversions, which is known to cause issues in Java, C++, etc.
Basically, the existing material is a bunch of existing incredibly complicated implementations, the odd blog post that just throws a bunch of code your way without really explaining the why/thought process behind it, and books that aren't worth the money.
The result is that you can of course piece things together (as I did), but it leaves you forever wondering whether you did it in a sensible way, or if you constructed some weird monstrosity.
To put it differently: you can probably build a garden by digging some holes and throwing a few plants around, but without the right resources it can be difficult to determine what the impact of your approach may be, and whether there are better ways of going about it. Oh and I'm aware there are resources on gardening, it's just a metaphor :)
The Dragon book has a chapter on type checking. It gives explanations on many topics. It has plenty of examples. It has type treatments on different areas of a language, like expression, array, struct, function, pointer, etc.
Despite being really old, its ideas and explanation on the topic are still relevant.
So that leaves blog posts for most developers actually implementing this stuff.
But the solution here is that when you finally figure out a good strategy to deal with something muddy like this is to write that better blog post :)
As for _when_ I'll do that, that depends on when I can convince my inner critic to actually commit to the idea :)
[1]: https://github.com/yorickpeterse/pattern-matching-in-rust
- Generics, especially inferring generic type params
- Recursive types
- Deeply mutable vs immutable types
- Type refinement based on checks/usage
- Giving good error messages for deep type mismatches (though I'm not sure TypeScript itself has figured this one out yet, lol)
etc. And even the stuff I've figured out, I figured out almost all from scratch (sometimes having to bail and take a totally new approach midway through). I would love to read a book giving me a proper bottom-up walkthrough of the current landscape of type system implementation
But that's an exception, and deliberately decided to be complex.
If you want ML-style total type inference when you expect the compiler to deduce the parameter and the return types of your functions, then yes.
Local variable type inference isn't hard at all, unless you want to do stuff like Rust: declare a variable without an initial value and infer its type from the first assignment downcode.