Hacker News Reader

Comment by kzrdude | Hacker News Reader

How to address this problem?

    fn foo(x: u32) { }
    let x: u16;
    let y: u16;
    foo(x * y);

`x` and `y` would have to be multiplied before they are widened to `u32`. This creates an overflow bug that may only be visible in the released code (release mode has arithmetic overflow checking off by default).

View on HN

A smart solution could be to have arithmetic operators automatically coerce the types to the type of their result, if the result type is already known.

Indeed, that is my intuition as well. This is the safest default behavior from the compiler, and even solves crazy expressions like:

    u64 = ((u8 + u16) * u32) / u8;

It's hard to reason about what a programmer would want that statement to do. Coercing everything to u64 is the safest option. The idea, though, is to allow the programmer to use explicit casts to define exactly what they want when the need arises. So:

    u64 = (((u8 + u16) as u16) * u32) / u8;

Would mean u16 addition, u64 multiplication and u64 division. So you get the benefit of safe, implicit type widening without losing the ability to micro-optimize when you want to.

The annoying thing is that (because of type inference) parts of the expression could be within different expressions:

    fn required_bytes(width: u16, height: u16) -> u64 {
        let size = width * height; // what's the type of size?
        size + 12
    }

True, type inference would make an ideal solution difficult. But I'm totally fine with the compiler failing to apply implicit casting when type inference is involved. This code is just as readable, if not better:

    fn required_bytes(width: u16, height: u16) -> u64 {
        let size: u64 = width * height;
        size + 12
    }

I just really don't want to have to write this all the time:

    fn required_bytes(width: u16, height: u16) -> u64 {
        let size = (width as u64) * (height as u64);
        size + 12
    }

If there is a type inferred, single character operator which can cast one numeric type to another, both sides can be happy.

This way of thinking leads to ASCII spaghetti as features are added over time.

I can sympathesize, but the last think I would want in a language is for benign looking refactorings to changes meaning. E.g.

    let a: u16;
    let b: u16;
    fn f(x: u32) -> ...

    f(a*b) // 32 bit result
    
    let x = a*b; // x is u16
    f(x)

Now there is a sane answer to this: define multiplication to always result in larger integer types, and require some explicit downcasting. But I'm not sure anyone will go for this.

Should be u16 at first (or u32 for overflow?) and promoted to u64 when returning from the function.

If the result type is already known and the result type is wider.

That same bug exists even if the function takes a u16.

It's not the same bug

In both cases the mistake happened when two 16-bit integers were multiplied and the result was truncated when stored to a 16-bit number. This is the point at which the information was lost, and this is the point that with different tradeoffs (note: I am not advocating for these alternatives) would either result in a 32-bit number or a runtime overflow check, leading there to no longer be a bug. The same bug would exist with a fully generic function, or even without a function at all. Passing a number that has already been truncated to a function that could have accepted a wider number is not a bug: the bug already happened.

Very interesting remark. How about: Disallow what you wrote, but allow

  fn foo(x: u32) { }
  let x: u16;
  foo(x);

This way you get the 'best of both world'?

Reply on news.ycombinator.com