4 ms·
I don't think there's a misunderstanding, I stand by what I said. Inferred return types don't make refactoring easier. In my experience they make it much more
by duped 3y ago
I don't think there's a misunderstanding, I stand by what I said.
Inferred return types don't make refactoring easier. In my experience they make it much more difficult, because you have to look at function implementation to understand what it does. Particularly for error handling, you always want to see what errors a function may return even in library code.
And all that said, there's no distinction to me between internals and externally facing code when it comes to quality and standards. If you have a function, even if it is called once, it should always have its return type annotated. It is more correct than leaving it to be inferred by the compiler, because you are explicitly annotating the intended behavior of the abstraction. This makes it easier to write correct code and for verifying it by a reviewer.
- jcparkyn 3y ago> Particularly for error handling, you always want to see what errors a function may return even in library code. Any half-decent tooling should do that, since GP was talking about compile-time type inference. Of course there are some situations where the type hints aren't available, but then we're back to a general discussion about type inference. FWIW, I don't actually agree with the idea that set-theoretic unions solve error handling, but I'm fully on-board with opt-in type inference for errors.
- valenterry 3y ago> Inferred return types don't make refactoring easier. In my experience they make it much more difficult, because you have to look at function implementation to understand what it does. My editor/IDE does show the inferred type to me though. I don't have to look at the function implementation. If I had to, I would agree with you.
- lal 3y agoI think locking use of a language into particular editors is a step several decades backward into Borland-land. I'm not at all confident that "just stop writing types in source code because the magic editor will show them anyway" is a better posture than "just have the magic editor auto-fill the types".
- valenterry 3y agoI totally get your point and it's valid. But I think this ship has sailed a long time ago. With modern languages having adhoc polymorphism, inheritance and different kinds of dispatch as well as extension methods etc., without an IDE you are already lost anyways. E.g. in rust you won't know where a trait is implemented and how it will behave, in kotlin you won't know if a method exists on the object or comes from somewhere else etc. The trend is going to more supportive but also more complex languages and tooling is naturally adapting to that.