Skip to content

Comment on An Inconsistent Truth: Next.js and Typesafety

Comments

My biggest gripe with inferred types is that you wind up with errors at random usage sites instead of at where the actual type “error” is. For example, with inferred return types you can wind up returning `a | b` when you thought you were returning `a` and this might actually be coincidentally fine for a bit until you use it somewhere that only takes `a` and you get a type mismatch. You can then trace backwards until you find the source of the bad assignment, which can be a few layers after a bit of inference, and this always felt antithetical to the improved ergonomics of types. As a result I always enforce explicit return type annotations with inference only within scopes. But TS happily supports a spectrum!

Yeah, type interference makes me paranoid. I'm always afraid of this kind of action at a distance. Say I have a function with inferred argument types, and I normally use it with an `int`. Then in one place I call it with a `float` argument. I worry that this will propagate back and cause a lot of variables to change to float, and thus change the semantics of my program.

Now I think inference works in one direction only (at least in languages with HM type interference), so this is a non-issue. But I'm often uncertain.

Anyway, in languages with optional typing like TS, I usually specify the types in function signatures manually to be 100% sure I understand what is going on.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.