3 ms·
I don't think UB has any particular bearing on a conversation about the "strength" of a type system, actually. There are plenty of non-type-related UBs, and tho
by DonaldPShimoda 7y ago
I don't think UB has any particular bearing on a conversation about the "strength" of a type system, actually. There are plenty of non-type-related UBs, and those UBs that are related to types do not necessarily make the type system weaker. C's type system is weak due to things like explicit casting that can circumvent any type safety, for example.
Python does no runtime checks of types. The type system employed by Python is effectively a structural (not nominal) system. So long as you provide things with the right structure (i.e., your objects provide the correct fields/methods), everything will work. But many people would like say that Python just "doesn't care" what you want because of the lack of any nominal type checking at any point.
- dllthomas 7y agoAny UB is type-related, in that "anything can happen" destroys type safety regardless of what definition of type safety we're using.
- DonaldPShimoda 7y agoUB does not mean "anything can happen". UB just means that the language specification makes no assertion about how to handle a given case — the behavior is literally just not defined. Any implementation of the language could choose to raise an error for such cases and that would conform correctly to the standard.
- dllthomas 7y agoNote that I specifically said "undefined behavior in C", where it pretty much means exactly that. It is not the same as "implementation defined". It's true that an implementation could in theory respect types even in the case of undefined behavior, but it is not promised by the language spec.