Many years ago (circa 2001) I wrote a letter to C/C++ User’s Journal (an odd but interesting name: users of C/C++? A user of languages implies an interesting relationship) that argued for automatic type inference in C++. Andrew Koening replied because my letter was in response to one of his articles saying more or less “yes, we want type inference but probably not in the next version of the standard”. It turned out later that he (and everybody else) misjudged how long it would take for the new standard to come out so type inference did end up in the C++11 standard.

Here we are now (don’t you just hate when articles or posts don’t specify the date of their writing? you should find the date of this writing at the top of the page) and I am working in a TypeScript code base. In the meantime C# and C++ and Rust and TypeScript (and many others that I have not used) have integrated type inference so it’s a natural part of the modern languages. And it does make life better, in general, although obviously I want both type inference and to know what the types are as I’m writing the code. Rust Visual Studio Code extension manages to do this (when it succeeds in parsing which is by no means guaranteed) by injecting the types as textual elements overlaying code.

TypeScript though has an additional feature of type inference of return type hence my motivation this morning to write this out. This type inference may sound great until you see the end result: function after under-specified function. This makes life easier when writing functions where the return type may often change (e.g. convert from sync to async adding Promise<...>) but it is absolutely horrific for reading code and “solving” types as one goes along. It is also bad for refactoring because you may incidentally change the return type of a function without realizing it and so rather than type system working for you… well now your lax typing has worked against you.

Sometimes there are appropriate comments of @return type but that just sends me right back to the loathed JavaScript where “happily” there are no types. Giving up on types is no solution. Even rendering types like Rust extension does is : it depends on something else entirely to make the code more understandable and the more you rely on such external tooling, the less likely it is that the code will be understood by the next person to read it.

I offer no solutions here. At worst of times the whole thing strikes me as one of those “demos nicely” things that get folks hooked but that at a certain point, just beyond the immediacy of writing working code, becomes a burden on maintenance and reading of the code, which is, after all, where we spend the majority of our time as programmers. At best of times, which I admit is most of the time, it’s just great to write code without being too specific about the types.

Last modified on 2025-01-29