[hansvm]

It's the same sort of bug that killed that Mars mission and the same reason some people insist on keyword parameters instead of ordered parameters. People make mistakes, and implicit conversions allow those mistakes to silently propagate. Given how easy it is to strongly type everything and use explicit conversions, the default for most nontrivial software should be closer to TFA rather than allowing implicit conversions or overloading the semantics of a type.

[SOLAR_FIELDS]

GIS are particularly prone to these sort of human caused accidents. Example is that some GIS take coordinate input as LatLon and some take LonLat.

Another good example is that very often when working with GIS you collate data from multiple sources, as a sibling comment indicates. These sources may be available in all sorts of different coordinate systems and projections and it’s extremely easy to get bad results that are difficult to verify they are bad by these types of bugs.

[tantalor]

You don't understand what implicit conversion is.

The Mars Climate Orbiter failed because an input was given in Newtons but expected in pounds, and the type of the variables was the same (float or whatever), so the compiler could not detect or prevent the error.

The root cause was using the same types for incompatible data, which allowed operations which should have been illegal.

If the variables had different types, then the compiler could use implicit conversion to automatically convert Newtons to pounds, and failure would be averted.

Implicit conversion does not allow mistakes to "silently propagate". It prevents the mistake in the first place.

[hansvm]

> You don't understand what implicit conversion is.

Please be nice, and check the site guidelines [0] if it's not obvious what the problem with that phrasing is.

Yes, implicit conversions are narrowly defined to be the thing you describe. Along with overloaded types and positional arguments, they all have the same properties I outlined -- the compiler can't protect you from minor typos, that error will tend to propagate far from the erroneous callsite, and there are relatively easy coding patterns to alleviate those issues. I thought those examples might be more familiar to enough people that it would give their brains something to latch on to when considering the problems with implicit conversions.

And we seem to disagree on this point, but IME implicit conversions cause many more bugs than they fix. A smattering of examples:

1. You can't implicitly narrow a numeric type without losing precision.

2. You can't implicitly narrow types in general without losing data or having some sort of error handling system, or having some sort of compile-time guarantee that the conversion is safe for this specific instance of the wider type. Without a very advanced compiler (even then, not for every problem), this will manifest as runtime errors and crashes.

3. You can't implicitly widen a numeric type without opening up yourself to all sorts of bugs. E.g., when evaluating `data & mask` you likely don't want the mask to be implicitly widened to the size of the data, unless you got especially lucky and were only extracting the low bits. Those sorts of problems are very common with integers, but floating-point widening is similarly dangerous from time to time.

4. You often shouldn't implicitly widen types in general because there usually isn't a good default state for the missing data. In the mask example from (3), the problem is that we don't know what the missing bits ought to be in the context of this particular problem, but that same problem manifests with class hierarchies and any other way you might represent converting a smaller type to a larger type.

Your example of implicitly converting between "equivalent" types is perhaps the best use case, and by far the one I have the fewest problems with. It's still not flawless though, and it's not safer than having two separate types while requiring explicit conversions.

[0] https://news.ycombinator.com/newsguidelines.html