I am Software Developer, currently interested in static type languages (TypeScript, Elm, ReScript) mostly in the frontend land, but working actively in Python also. I am available for mentoring.
Interesting but take into consideration that for TS if you would remove return type annotation from gerFromBarn it would infer it as type with structure matching Cow, it would not say directly it is Cow but thanks to structural typing it would be allowed to use as Cow as it has all needed properties.
So the problem is that we by purpose made annotation which makes return as less specific type. Is this is an issue, looks like more like done in a purpose to force function consumer to check what Animal it gets.
In my experience such things like annotating wrongly function by less specific type doesn't happen by mistake, you do it because you want, and consumer needs to double check. In other words I see no issue in that.
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.
Interesting but take into consideration that for TS if you would remove return type annotation from
gerFromBarnit would infer it as type with structure matchingCow, it would not say directly it isCowbut thanks to structural typing it would be allowed to use asCowas it has all needed properties.So the problem is that we by purpose made annotation which makes return as less specific type. Is this is an issue, looks like more like done in a purpose to force function consumer to check what Animal it gets.
In my experience such things like annotating wrongly function by less specific type doesn't happen by mistake, you do it because you want, and consumer needs to double check. In other words I see no issue in that.
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.