Comment by fpgaminer | Hacker News Reader

Comment by fpgaminer | Hacker News Reader

I had the opportunity to work with Rust >1.0 recently, implementing an image processing algorithm. Knowing that the compiler was looking out for me, a wingman of sorts, was quite the pleasant experience. When coding in C I have a very paranoid mentality, constantly questioning every line of code and its impact on program state/memory. It results in my C code being almost always free of memory related bugs, but the work is absolutely _exhausting_. Rust was great in this regard, dramatically reducing the amount of mental capacity expended while coding. Either the compiler would catch the bugs, or worst-case a run-time assert would catch it and point me directly to the problem.

The major criticism I came away with, due in part to the type of program I was coding, was for Rust's lack of implicit type casting (more specifically, widening). What I mean is, adding a u8 and a u16 is an error in Rust. Rust will refuse to implicitly cast the u8 to a u16. These situations came up very frequently while implementing my program because I had to do a lot of optimized, low-level math. The scattering of type casts throughout the program resulted in clutter without any obvious benefit.

When I looked into the problem, the arguments I saw against it were often explanations that Rust is meant to be explicit and non-magical. But Rust, for example, already has type inference which I classify as "magical". Implicit type widening is hardly magical. And I don't see how it would be confusing or result in bugs, as long as only safe widening is done implicitly.

I think those involved in the Rust project were just scared off from it because of C's bizarre implicit type casting rules which result in bugs for typical programmers. I can understand that, but it's not like it can't be done better in Rust. Besides, if Rust is meant to be a system programming language, won't math between differing types come up often? And wouldn't handling those cases gracefully be a boon to productiveness in Rust?

I definitely agree, this is a pain point in Rust today, and it's something the core team would like to address. You might glance at the thread here for some of the tradeoffs: https://internals.rust-lang.org/t/implicit-widening-polymorp...

If we can reach consensus on a design, such a feature can be easily implemented. I'd love to see an RFC on the topic (https://github.com/rust-lang/rfcs)!

Here's why you might not want to have type conversion. I ran into this today:

class String {

  int find(char needle, int startIdx);

};

I ended up calling:

   int idx = find(startIdx, ';');

C++ happily converted my char to an int, and my int to a char, no warning or anything. Surprisingly, the code appeared to work for months, and then when I upgrade Xcode to the beta, it started failing. Weird.

I end up casting stuff when I do math, anyway, because I can never remember when 'int op float' and 'float op int' results in an int or a float, and every time I don't it ends up as a truncated int when I wanted a float in [0, 1]. So, a little more painful to have to cast stuff around, but at least you find out quickly about my find() bug and you don't end up with something like

   if (secondsFromMidnightInFloat / 86400 > .5) {...}

always fails. I can't tell you how much time I've wasted tracking something like that down, despite my diligence in adding (float). That and that stupid "->" for pointers drive me nuts. Even more than header files.

From the discussion linked[1] in another reply at your level, I believe the proposed automatic type conversions are only for when there's no data loss, and there needs to be explicit conversions whenever loss of information is possible. That is, it's implicit for i32 -> u32, or i32 -> i64, but not for something like i32 -> i8 (such as the int to char conversion you mentioned), which would need to be explicitly converted.

1: https://internals.rust-lang.org/t/implicit-widening-polymorp...

i32 -> u32 is not lossless, since u32 cannot represent negative numbers. And indeed that's not listed in the implicit conversion table in the page you linked to.

You're right, I want clearly thinking about that. Thanks.

The first case will be detected by -Wconversion, however you have to enable it.

For the second case, correct me if I'm wrong, but I think both float / int and int / float have a float result. In fact, pretty much all operations involving an int and a float will have a float result.

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

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'?

As a hardware guy who has never touched rust, and I know nobody will agree with me: the solution is to not have type inference. You knew you wanted u16 or whatever to begin with. For low level programming I think explicitly defining type makes so much more sense.

I'm not sure that's the solution

  int8 x = 12;
  int8 y = 84;
  int16 z = x + y;       // ERROR: compiler is stupid

Wait, did you mean

    int16 z = (x + y) as int16;

or

    int16 z = (x as int16) + (y as int16);

?

I think with C# the addition is mostly or always promoted to an int. So the following gives an error.

byte foo = 4; byte boo = 86; byte arglebargle = foo + boo; // cast monkey! cast!

I remember old assembly language guys annoyed at the types of math available with high level languages. I think they were a bit crusty but still they had a point about inability to manage precision without big hammers.

At least the C# way forces you to think about whether you're loosing precision. But I dislike having to add casts. I use casts a lot, but I distrust the because they hide errors. I find myself really wanting safe operators and unsafe ones. Safe as in, overflow results in a hard fault that I can catch. Unsafe means overflow is silent.

I think that although the commented above used `as`, he meant it as pseudocode and not C#, especially since C# is rarely used for low-level or perfomance-critical stuff where you would use int8 instead of int16 for optimization (in my experience).

I was just using C# as an example of an alternative way of handling calculations.

The comment about assembly comes from remembering a conversation with an older firmware guy. In his world multiplying two 32 numbers resulted in a 64 bit result. And division was 64 bits divided by 32 bits with a 64 bit result, 32 bit result plus a 32 bit remainder.

I think his thoughts on C's 32 bit number X 32 number => 32 bit result can be summed up in a single word: gah!

That depends largely on language semantics. Ideally, a language would either guarantee that overflows can't happen (via dependent/refined types), make sure that addition is `(int8, int8) -> int16`, or guarantee modular arithmetic. In any case, the second interpretation looks overall superior.

Not having type inference is a non-starter in Rust. Lifetimes would be totally impractical, and you couldn't use closures.

> As a hardware guy who has never touched rust, and I know nobody will agree with me: the solution is to not have type inference.

How is that a solution to OP's problem?

It's not a solution- it's saying that what the OP characterized as a problem is a feature, not a bug. I don't know if I agree (maybe, maybe not, maybe "it depends"), but that's the answer to your question.

As a Rust newbie wrapping a C API, I ran into a baffling error for something like wstr.s[0 .. wstr.len], where the s field is an array, and the len field is a u16.

I like static typing with inference, but I'm still getting the hang of the Rust type system. In this case, a little leniency would have been nice.

Reply on news.ycombinator.com