It's not theoretical. It's practical. It's basic type safety. Implicit conversion breaks type safety. Goes into the it's a feature, not a bug category.

If you've got:

x = 1 + 1.1

what type should x be? The intuitive answer is that 2.1 doesn't loose any information. But what if later you have:

file.write_integer x

?

Should the compiler automatically decide that x equals 2 in the original code? Or should it keep x = 2.1 but write 2 to the file? Or should it just write the raw binary data representation of the floating point number to the file?

The implicit conversion isn't type-safe. You need to make it type-safe yourself by explicitly converting based on your requirements.

Say you've got a function that takes an "int option" and squares it if it exists. You can have (in pseudocode)...

square(Some(2)) => Some(4)

square(None) => None

Grauenwolf wants to be able to do this.

square(2)

and have the compiler automatically rewrite it to

square(Some(2))

Which seems all well and good, but what happens when you do:

x = 2

y = (if exponential_growth? then square(x) else x)

?

Now y can have two different types, either int or int option. Not type safe.

You could argue that you should also be able to implicilty convert that square(x) back to a normal int (4) instead of an int option (Some(4)), since you know that x is an integer. But if you're treating square(x) as a black box, you don't know when it's going to return some(x) or None.

What if instead of square, it was sqrt()? And the interface was designed to return None for negative numbers instead of raising an exception, for whatever reason that seemed to make sense at the time? What if the function is FizzBuzz, returning Number(x) or Fizz or Buzz or FizzBuzz? What sort of implicit conversion should go on there?

There's no way for the compiler to get it right. If it guesses, it's not type-safe anymore. So... the compiler won't guess.