Google Feedback on TypeScript 3.5
> (I might suggest the underlying problem in this code is relying on inference too much, but the threshold for "too much" is difficult to communicate to users.)<p>This is a <i>very</i> outstandingly interesting line out the whole writeup.<p>I like the writeup in its entirety for being very balanced and thoughtful, but this line in particular really stands out to me as worth more thought for anyone interested in language and type system design.<p>Inference is great.<p>Except... when it's not.  When it's "too much".  When it starts making breaking changes appear "too distantly".<p>It's an interesting topic to reflect upon, because the inference isn't <i>making</i> a breakage; just shifting around where the breakage <i>appears</i>.  (And this makes it hard to ever direct criticism at an inference mechanism!)  But this kind of shifting-around of the breakage appearance can be a drastic impact on the ergonomics of handling it: how early it's detected, how close to the important change site tooling will be able to point the coder, etc.  That's important.  And almost everything about it involves the word "too" -- which means the area is incredibly subjective, and requires some kind of norm-building... while not necessarily providing any clear place for that norm-building to center around.<p>I don't have a point here other than to say this is interesting to reflect on.  I suspect the last chapter on type inference systems has not yet been written.  Can an inference system be designed such that it naturally restrains "too" much use of it?