5 ms·

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 whate

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.

tomp 11y ago
I'm not sure that's the solution int8 x = 12; int8 y = 84; int16 z = x + y; // ERROR: compiler is stupid
- continuational 11y ago
  Wait, did you mean int16 z = (x + y) as int16; or int16 z = (x as int16) + (y as int16); ?
  - Gibbon1 11y ago
    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.
    - golergka 11y ago
      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).
      - deleted 11y ago
        [deleted]
      - Gibbon1 11y ago
        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!
  - tomp 11y ago
    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.
pcwalton 11y ago
Not having type inference is a non-starter in Rust. Lifetimes would be totally impractical, and you couldn't use closures.
tomjakubowski 11y ago
> 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?
- mwfunk 11y ago
  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.

tomp 11y ago

I'm not sure that's the solution int8 x = 12; int8 y = 84; int16 z = x + y; // ERROR: compiler is stupid

continuational 11y ago
Wait, did you mean int16 z = (x + y) as int16; or int16 z = (x as int16) + (y as int16); ?
- Gibbon1 11y ago
  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.
  - golergka 11y ago
    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).
    - deleted 11y ago
      [deleted]
    - Gibbon1 11y ago
      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!
- tomp 11y ago
  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.

pcwalton 11y ago

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

tomjakubowski 11y ago

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

mwfunk 11y ago
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.