> Traditionally, strong/weak typing refers to how easy it is to "trick" the type system into doing something it wouldn't otherwise want to do.

Right, and autoconversion according to spec is something the type system does want to do. It uses type information to do it, in fact.

I feel like I'm not explaining myself well haha.

The C type system is perfectly happy with casts. The behavior of casting is well specified. And yet the fact that the type system supports casts to the extent that it does means that C's type system is weak.

But this is not the only metric to judge a type system's "strength", and it was poor word choice on my part that I phrased my statement in a way that made it seem so.

JS's type system is weak because of implicit coercion. The fact that values of type X can be coerced into values of type Y at runtime without any notification to the user is indicative of a weak type system, regardless of how well-specified this behavior is. Weak type systems do not lack specification; they lack a feeling of types being "rigid" or "strong". If your values can be converted to different (semantically incompatible) types, then your type system is weak because it isn't telling you anything.

A strong type system is one which stands up to you and says "No, I won't let you do that because I don't think that's what you meant to do." A weak type system is one which does its best to let you do whatever you want. Again, the specification of the behavior of various operations within the type system (such as casting or coercion) is not the determining factor in assessing the "strength" of the type system.

> A weak type system is one which does its best to let you do whatever you want.

... or plain doesn't care?

Maybe? I think that phrasing is lacking in some clarity. Does Python care? Most people would say "no", but Python is strongly typed because you simply cannot use values with the wrong attributes. (The nominal types don't matter in Python, generally, but the structural types do.)

Python says no in a (sufficiently) sensible way at runtime to certain classes of things, and tries to let you do what you want about others. I was referring to things like undefined behavior in C as instances where the language "plain doesn't care" what you want.

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.

Any UB is type-related, in that "anything can happen" destroys type safety regardless of what definition of type safety we're using.

UB 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.

Note 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.