[breatheoften]

I think this article makes some really valid points. Many languages try to address the spooky action at a distance type errors by requiring explicit annotation of types at certain boundary type conditions like function argument and return arguments -- which can help but can still also being annoying when the type system knows the types you want to write but you still have to figure them out and type them in yourself. A lot of times it's less cognitive load to verify that a type declaration is what you expect than it is to write it yourself (something we often do with tools like rust-analyzer or highlighting over variables in ide to see the type).

Personally I'd like to see languages embrace "format on save" as an explicit part of language ui to improve ergonomics here. Firstly, a first class auto formatting tool is just great and spamming cmd-s as you write code until it auto formats nicely is a really quick way to observe and address syntax issues -- to me that part of the experience is already important enough to explicitly incorporate making that developer experience work well a goal of language design.

But secondly -- if you do embrace auto format on save at language design level, there's a lot more you can do than just auto format the code! You also gain a really nice channel for communicating information about "program change" to the developer. Say you allow in the language to differentiate between inferred and not inferred types -- and then at auto format time, the inferred types are explicitly added to the code (in some heuristically useful set of places-- or even just everywhere that a non type inferenced language would require explicit types).

In that world, as you make changes to the code, your git diff state is going to start giving you a lot of potentially useful feedback about what actually happens in your program when you make certain changes. Additionally because the inferred types are automatically added -- you can easily have a mode to hide them when you want a less noisy view. Mayb the convention would become that committeed code is always serialized to a form that conveys more of the statically knowable program information by default -- which your ide can hide to give you a more streamlined view -- rather than the other way around). And then the parts of your code you know are boundaries or apis or not expected to change types, you just update the annotation to indicate that the type is not supposed to be reinferred and a type error will be issued if it doesn't match instead of being updated. Now you've got a nice way of constraining program evolution in desired directions to help tame complexity or at least force explicit acknowledgement as certain assumptions about the program structure become invalid over time ...

[cryptoxchange]

Do you have any sources or links where you or others expand on these ideas? I daydream about something like this every so often.

[williamcotton]

In my experience IDEs and language servers for a language like F# have a convenient "Add explicit type annotation" that will do just as you're suggesting.