4 ms·

Language that value strong type-safety guarantees won't respond to a request for "1" + 1 by quietly coercing one value to the other's type and moving along as i

Language that value strong type-safety guarantees won't respond to a request for "1" + 1 by quietly coercing one value to the other's type and moving along as if nothing strange happened. They'll generate a type mismatch error because adding an integer to a text string is undefined operation.

dragonwriter 12y ago
Perhaps (though, discarding the emotional language of "quietly" and "as if nothing strange happened", there's all kinds of things in strong, statically-typed languages that aren't much different structurally from that, though if they did it would usually be by way of an operator working on a typeclass which included a total, rather than partial, conversion function to support the operation, so that the semantics of addition of string and whatever numeric type it was supported with would be well defined for all strings, rather than being only defined for particular strings; then again, its not like Haskell doesn't have functions that crash on values of an appropriate type but unsuppored specific values, so maybe not), but, in any case, f a b (or f(a,b) or (f a b) or a op b, depending on the syntax of the languages involved and the kind of function/operator at issue) having two different meanings in two different languages (specifically, two that can be included in the same file), which was what was complained about that example, isn't something that only occurs with that example, and it certainly can occur in strong statically-typed languages without even considering hypothetical constructs.