DEV Community

Discussion on: On Subtyping vs. Row Polymorphism, information loss, and actionable error messages

Collapse
macsikora profile image
Pragmatic Maciej

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.

Collapse
maxheiber profile image
Max Heiber Author • Edited

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.