6 ms·

So when do we find out why Rust can't multiply pi by 2? I mean, what is the point of making float x int an unsupported operation? I understand they're differe

So when do we find out why Rust can't multiply pi by 2? I mean, what is the point of making float x int an unsupported operation? I understand they're different types, but that doesn't seem like a good enough reason. Isn't it obvious that the output type should be float? So why not just cast the int to a float and multiply them and output a float, like other languages do?

HWR_14 4y ago
Its not obvious at all to me the result should be a float. I think the times I'm going to accidentally multiply a float by an int outweigh the times I want to lazily multiply a float by an int. And, some percentage of that time I would want an int anyway!
aw1621107 4y ago
For what it's worth, Rust isn't the only language that does this. OCaml also doesn't allow mixing ints and floats, and actually has entirely different operators for int and float operations [0]. I think Haskell might do something similar [1]? I don't know for sure why Rust chose this route, but I would guess it's a mix of type inference/type system considerations and a desire to avoid potential implicit loss of data. [0]: https://stackoverflow.com/questions/64244351/why-does-ocaml-have-mandatory-distinct-float-and-int-literal-syntax https://stackoverflow.com/questions/64244351/why-does-ocaml-... [1]: https://stackoverflow.com/questions/19019093/haskell-multiplying-int-and-float-within-a-function https://stackoverflow.com/questions/19019093/haskell-multipl...
- SAI_Peregrinus 4y ago
  Rust just takes "explicit is better than implicit" further than most. No hidden type casts. Floating point operations aren't quite the same as integer operations. Float operations aren't commutative, for one. So it's nice to be suae you really intended to use a float operation on an integer by requiring an explicit cast, so you can get the order correct.
- agumonkey 4y ago
  And considering the influence of ml in rust roots it's not surprising.
- tome 4y ago
  In Haskell you use the same operator for multiplying two Ints as you use for multiplying two Floats (you can't multiply an Int by a Float without converting one to the other).
  - dllthomas 4y ago
    There's also magic for numeric literals.
ajxs 4y ago
> "Isn't it obvious that the output type should be float?" To you that might be obvious. The compiler can't infer what your intentions were from your code. > "So why not just cast the int to a float and multiply them and output a float, like other languages do?" What if the result is being stored in an integer type, how should this be handled? In order to compile the code in the ways your post specifies the compiler has to make many assumptions. Choosing to minimise the amount of assumptions made by the compiler about types is part of 'strong typing'. Being a systems programming language, it needs to be concerned with the underlying representation of the data. What if the result variable only has 8-bits, and can't reasonably represent a floating point type at all? I do lots of coding in Ada, which has a strong type system. It allows you to specify arbitrary ranged numeric types. This allows you to better semantically describe your problem domain. You could have a specific numeric type representing the number of slices in a pizza (an integer), and one specifying the number of kilometres between two points on a map (a float). Multiplying one by the other might not make sense in your problem domain. The compiler would prevent you making what it assumes would be an erroneous calculation.
- dasil003 4y ago
  Wait hold on, why are you jumping straight to "what the compiler can infer"? Compilers (and type systems) are written by and for humans, so first tell me the use case for multiplying a float by an int that does not lead to a float and justify why we should optimize for that case.
  - fennecfoxen 4y ago
    Sure. Multiplying a float by an int that leads to AN ERROR because you mixed up your types and you are now losing precision somewhere or other. Avoiding that sort of an error at compile-time is right there at the heart of the core premise of Rust, so Rust should optimize for it.
    - Turing_Machine 4y ago
      Except that in the real world people want to multiply floats by ints all the time, and they don't want to go through a lot of type-wankery to do it.

HWR_14 4y ago

Its not obvious at all to me the result should be a float. I think the times I'm going to accidentally multiply a float by an int outweigh the times I want to lazily multiply a float by an int. And, some percentage of that time I would want an int anyway!

aw1621107 4y ago

For what it's worth, Rust isn't the only language that does this. OCaml also doesn't allow mixing ints and floats, and actually has entirely different operators for int and float operations [0]. I think Haskell might do something similar [1]? I don't know for sure why Rust chose this route, but I would guess it's a mix of type inference/type system considerations and a desire to avoid potential implicit loss of data. [0]: https://stackoverflow.com/questions/64244351/why-does-ocaml-have-mandatory-distinct-float-and-int-literal-syntax https://stackoverflow.com/questions/64244351/why-does-ocaml-... [1]: https://stackoverflow.com/questions/19019093/haskell-multiplying-int-and-float-within-a-function https://stackoverflow.com/questions/19019093/haskell-multipl...

SAI_Peregrinus 4y ago
Rust just takes "explicit is better than implicit" further than most. No hidden type casts. Floating point operations aren't quite the same as integer operations. Float operations aren't commutative, for one. So it's nice to be suae you really intended to use a float operation on an integer by requiring an explicit cast, so you can get the order correct.
agumonkey 4y ago
And considering the influence of ml in rust roots it's not surprising.
tome 4y ago
In Haskell you use the same operator for multiplying two Ints as you use for multiplying two Floats (you can't multiply an Int by a Float without converting one to the other).
- dllthomas 4y ago
  There's also magic for numeric literals.

ajxs 4y ago

> "Isn't it obvious that the output type should be float?" To you that might be obvious. The compiler can't infer what your intentions were from your code. > "So why not just cast the int to a float and multiply them and output a float, like other languages do?" What if the result is being stored in an integer type, how should this be handled? In order to compile the code in the ways your post specifies the compiler has to make many assumptions. Choosing to minimise the amount of assumptions made by the compiler about types is part of 'strong typing'. Being a systems programming language, it needs to be concerned with the underlying representation of the data. What if the result variable only has 8-bits, and can't reasonably represent a floating point type at all? I do lots of coding in Ada, which has a strong type system. It allows you to specify arbitrary ranged numeric types. This allows you to better semantically describe your problem domain. You could have a specific numeric type representing the number of slices in a pizza (an integer), and one specifying the number of kilometres between two points on a map (a float). Multiplying one by the other might not make sense in your problem domain. The compiler would prevent you making what it assumes would be an erroneous calculation.

dasil003 4y ago
Wait hold on, why are you jumping straight to "what the compiler can infer"? Compilers (and type systems) are written by and for humans, so first tell me the use case for multiplying a float by an int that does not lead to a float and justify why we should optimize for that case.
- fennecfoxen 4y ago
  Sure. Multiplying a float by an int that leads to AN ERROR because you mixed up your types and you are now losing precision somewhere or other. Avoiding that sort of an error at compile-time is right there at the heart of the core premise of Rust, so Rust should optimize for it.
  - Turing_Machine 4y ago
    Except that in the real world people want to multiply floats by ints all the time, and they don't want to go through a lot of type-wankery to do it.