4 ms·
Isn't this just the classic issue of inferred typing coming back to bite us in the way everyone originally predicted? Go runs into the same issue where wildly
by munk-a 3y ago
Isn't this just the classic issue of inferred typing coming back to bite us in the way everyone originally predicted? Go runs into the same issue where wildly different types may be considered the same based purely on coincidental naming and matching against interfaces the original authors had no intent to match against. At the end of the day I think the easier system to work with is one in which all type compatibility needs to be explicitly declared - if your array is iterable defining that it implements iterable lets your compiler shout at you if iterable suddenly gets another abstract method that you didn't implement - and it makes sure that if you add a method `current` to a class it doesn't suddenly means that it properly supports iterable-ity.
Determining types by what things appear to do instead of what they state they do seems like a generally unnecessary compromise in typing safety that isn't really worth the minuscule amount of effort it can save.
- skybrian 3y agoI haven’t run into interfaces coincidentally matching in Go. Have you? It might happen more easily for primitive types, though, and Go does have a way to declare new types: type UserId string
- klysm 3y agoAre these simple aliases or nominally distinct types?
- yencabulator 3y agoNominally distinct. https://go.dev/play/p/4am-a1i4_ox https://go.dev/play/p/4am-a1i4_ox
- Aeolun 3y agoI mean, they have to stay backwards compatible with Javascript. That kind of limits your options.
- munk-a 3y agoNot particularly - they could use distinct tokens (i.e. these brandings) on all types implicitly.
- cageface 3y agoThe other problem I've found with structural types in Typescript is that it can lead to some very complex type specifications. Instead of carefully thinking about and naming the entities in your system you can get some very hard to parse type spaghetti.