3 ms·
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 in
by fpgaminer 11y 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
}
- echaozh 11y agoIf there is a type inferred, single character operator which can cast one numeric type to another, both sides can be happy.
- xyproto 11y agoThis way of thinking leads to ASCII spaghetti as features are added over time.
- dgoldstein0 11y agoI 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.