Hacker News Reader

Comment by F-0X | Hacker News Reader

I need to get this gripe off my chest. I want types on the left, and not optional.

I read the main function first. I saw that call to countOccurances, without an argument. I was confused how it was going to count occurances if it didn't know what it was looking for. Then I noticed the implementation of this method above.

Had there have been a type of Map<string, int>, I'd have reasoned what it does easily.

I hate type inference, it does not help.

View on HN

Here the problem seems to be especially that the return type is infered. Usually the return type of a function is regarded as belonging to the functions interface and should be accessible without reading the implementation.

Muon always allows you to specify a return type for clarity, though. The key point is that you have the option not to. Not all code is created equal. For library functions that are used by many others it is probably a good idea to add explicit return types, but if you're quickly iterating on a prototype it can be nice to not have to specify them.

I should also add that a language server will really help here. The tooling can just tell you what the return type of a given function is. I can also imagine building some tooling that automatically adds return type annotations if they are missing (which would be quite easy to build). Such a tool could be used as a commit hook to enforce a certain coding standard for teams that would prefer this.

The problem is with contract versioning. If you're writing a library, and your return types are derived rather than explicit, it's way too easy to break your clients by changing the type without even noticing. So maybe require it for public interfaces?

I'm not yet convinced to make it absolutely required, but some kind of warning/linter message would definitely be useful for this.

Reply on news.ycombinator.com