Disallow all implicit casting

[certik]

We should disallow all implicit casting. In particular, this should not work anymore:

x: f64
y: f32
y = 1.0
x = y

Rather, one would need to do x = f64(y). If there is a better way for the syntax of these casts, we could use it, but the f64(y) might work both in CPython and LPython.

The tricky part is what to do with constants. I think integers like 3 should be i32 and floats like 3.0 should be f64.

Then how to do:

x: f32 = 3.0

Here we could do:

x: f32 = f32(3.0)

And the same for:

n: i64 = i64(3)

I am thinking let's start with this approach. We can always relax these restrictions later in a backwards compatible manner, but it's hard to put them back on without breaking people's codes.

[czgdp1807]

Makes sense to me. Let's go ahead with this.

[certik]

Since in Python you cannot do x: f64 = 1 (because CPython and LPython would have different types), and instead you are forced to do either x: f64 = 1.0 or x: f64 = f64(1), it seems that we should not bother with allowing y: f64; x: f64 = y + 1, and simply force either x: f64 = y + 1.0 or x: f64 = y + f64(1).

So let's try to disallow all implicit casts. Then see where we are and if there are some use cases where it would be really helpful to relax this, we can always do that in the future.

[certik]

So it seems to me, we should:

• disallow all implicit casting everywhere (comparisons, assignment, function calls, etc.)
• implement i32(x), i64(x), f32(x), f64(x) for casting.
• See how things goes as we implement more of the standard library etc.
• If it later turns out that it is too difficult for end users, we can always relax these rules in a backwards compatible manner; we can also introduce a compiler option --allow-implicit-casting if needed.

[Thirumalai-Shaktivel]

Fixed in this PR: #1271