This was based on a real bug in some typed Erlang code (just smaller and renamed)–I suppose the situation is a bit different because afaik one can't leave the return type off in the Erlang typed language, function annotations are all or nothing.
That said, return type elision is one of my least-favorite TS features! If all is going well, then my reason for calling one function over is exactly that I want that juicy return value. Hiding what it is seems perverse at best.
The real example involved the equivalent of TS' string literal types. So it was more like returning string instead of a "server".
What likely happened is that the author either got lazy, didn't know about the more literal form of type, or intended to return the more general type in the future but never got around to it. Part of the pain is that we can't really know without a combination of code archeology and luck.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This was based on a real bug in some typed Erlang code (just smaller and renamed)–I suppose the situation is a bit different because afaik one can't leave the return type off in the Erlang typed language, function annotations are all or nothing.
That said, return type elision is one of my least-favorite TS features! If all is going well, then my reason for calling one function over is exactly that I want that juicy return value. Hiding what it is seems perverse at best.
The real example involved the equivalent of TS' string literal types. So it was more like returning
stringinstead of a"server".What likely happened is that the author either got lazy, didn't know about the more literal form of type, or intended to return the more general type in the future but never got around to it. Part of the pain is that we can't really know without a combination of code archeology and luck.