> In my 23 years of programming, I have never experienced this bug. I've also never heard of anyone else experiencing this. I've even said this in fora where I should have had someone pop up to correct me
This is a joke I’m not getting, right?
Somebody is forgetting that comparison and arithmetic operators are an interface on a type, and that almost every popular language (even many that are ostensibly “statically typed”) have ubiquitous nightmare scenarios surrounding implicit casts.
And of course, it’s also common where data comes from an i/o source and then is magically assigned a type by an ORM or deserializer or framework helper.
Or when working with large projects with lots of modularity and abstract interfaces, where the names of parameters, methods, and members become increasingly generic.
People work around these issues and learn how to avoid them with good practice, but they happen every day.
For example, in Scala's standard library there are a ton of implicit conversions that results in some truly horrendous behavior where types get autoconverted hither and thither if they don't match. So instead of a simple type error, you get nonsense when the compiler manages to find a way to cast A to B. And then you might get a crash because you used B wrong.
I have heard that this is one of the things that Scala 3 fixes, but I haven't done any programming in that yet.
> Somebody is forgetting that comparison and arithmetic operators are an interface on a type, and that almost every popular language (even many that are ostensibly “statically typed”) have ubiquitous nightmare scenarios surrounding implicit casts.
For what it's worth (and in the context of the article), Go doesn't do implicit conversions like this: you get a compiler error if you compare an int32 to a uint64, for example, and you always have to convert one to the other type explicitly. That goes for comparisons and arithmetic (neither of which are overloadable in Go).
> and that almost every popular language (even many that are ostensibly “statically typed”) have ubiquitous nightmare scenarios surrounding implicit casts
Well, C/C++ implicit cast are very, very bad, but this doesn't mean that another language can't create sensible 'implicit cast' rules.
No int <-> unsigned implicit cast but allow intY <-- intX implicit cast when Y>=X (same for unsigned).
This is a joke I’m not getting, right?
Somebody is forgetting that comparison and arithmetic operators are an interface on a type, and that almost every popular language (even many that are ostensibly “statically typed”) have ubiquitous nightmare scenarios surrounding implicit casts.
And of course, it’s also common where data comes from an i/o source and then is magically assigned a type by an ORM or deserializer or framework helper.
Or when working with large projects with lots of modularity and abstract interfaces, where the names of parameters, methods, and members become increasingly generic.
People work around these issues and learn how to avoid them with good practice, but they happen every day.