Hacker News new | ask | show | jobs
by fpgaminer 3960 days ago
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
    }
2 comments

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