5 ms·

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

by F-0X 8y ago

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.

laszlokorte 8y ago
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.
- nickmqb 8y ago
  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.
  - int_19h 8y ago
    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?
    - nickmqb 8y ago
      I'm not yet convinced to make it absolutely required, but some kind of warning/linter message would definitely be useful for this.

by F-0X 8y ago

laszlokorte 8y ago

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.

nickmqb 8y ago
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.
- int_19h 8y ago
  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?
  - nickmqb 8y ago
    I'm not yet convinced to make it absolutely required, but some kind of warning/linter message would definitely be useful for this.