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