4 ms·

OT: Is Rust using operator overloading? Is user-defined operators a possibility in the future? I googled it and the most I could find was this: http://www.redd

by Dewie 13y ago

OT: Is Rust using operator overloading? Is user-defined operators a possibility in the future? I googled it and the most I could find was this: http://www.reddit.com/r/rust/comments/1le6vu/i_wrote_a_prototype_parser_combinator_in_rust_and/cbyh50y http://www.reddit.com/r/rust/comments/1le6vu/i_wrote_a_proto...

steveklabnik 13y ago
You want to check out std::ops http://static.rust-lang.org/doc/master/std/ops/index.html http://static.rust-lang.org/doc/master/std/ops/index.html
kibwen 13y ago
Operator overloading, yes. But we place some restrictions on which types you can overload in order to keep things sane (oversimplified explanation: you must have declared the types yourself in order to overload operators on them). We also discourage the wanton overloading of operators to mean completely random things, as you might have encountered in C++. As for user-defined operators, if you mean something like Haskell's custom infix operators then no, I don't believe there are any plans for those.
- Dewie 13y ago
  I think that Reddit thread was interesting. The syntax is taken from Haskell, but someone brought up ditching precedence and only associating in one direction, which I guess is simpler than operator overloading(?)
- JoshTriplett 13y ago
  > As for user-defined operators, if you mean something like Haskell's custom infix operators then no, I don't believe there are any plans for those. Do the Rust designers actively oppose having them, or just not have any concrete plans to add them?
  - kibwen 13y ago
    Merely lukewarm, I think. There are simply much higher priorities to focus on at the moment. Who knows what Rust 2.0 might hold!
    - pnathan 13y ago
      I've always found the profusion of infix operators in Haskell to be heinously confusing, and seriously degrades readability and usability of libraries.limits on the o
      - Dewie 13y ago
        The problems I see with infix operators are: - It's not necessarily obvious what is an infix operator - Precedence and associativity I think Haskell has solved the first one: with all non-alphanumeric symbols in expressions being infix operators, and likewise for alphanumeric functions written with backticks. But precedence and associativity is not obvious, since that is something that you can customize. I think that user-defined infix operators with some severe limits on choosing precedence and associativity is a good compromise (many use backticks on functions in Haskell, and that has a default precedence).
- Arelius 13y ago
  That's great. Really, the only case in C++ I want operator overloading, is to implement standard math operators on custom types, like Vector3s, Matrices, and Bignums.
  - humanrebar 13y ago
    Assuming you use smart pointers, you'll want overloading for pointer operators as well, even if you're not implementing the smart pointers yourself.
    - Arelius 13y ago
      I'm not however sure that applies to Rust. And frankly I care a lot less about the pointer operators for smart pointers. Any old accessor is decent, and I find the overloaded pointer operators sometimes confusing. At the very least it's not quite as obvious as it is for math operators.
mcguire 13y ago
There is this: http://maniagnosis.crsr.net/2013/04/operator-overloading-in-rust.html http://maniagnosis.crsr.net/2013/04/operator-overloading-in-... I think a current version should still be similar, although I haven't had a chance to take a look at the code for 0.9. I also notice that I forgot to update that with the double-dispatch approach.

by Dewie 13y ago

steveklabnik 13y ago

You want to check out std::ops http://static.rust-lang.org/doc/master/std/ops/index.html http://static.rust-lang.org/doc/master/std/ops/index.html

kibwen 13y ago

Operator overloading, yes. But we place some restrictions on which types you can overload in order to keep things sane (oversimplified explanation: you must have declared the types yourself in order to overload operators on them). We also discourage the wanton overloading of operators to mean completely random things, as you might have encountered in C++. As for user-defined operators, if you mean something like Haskell's custom infix operators then no, I don't believe there are any plans for those.

Dewie 13y ago
I think that Reddit thread was interesting. The syntax is taken from Haskell, but someone brought up ditching precedence and only associating in one direction, which I guess is simpler than operator overloading(?)
JoshTriplett 13y ago
> As for user-defined operators, if you mean something like Haskell's custom infix operators then no, I don't believe there are any plans for those. Do the Rust designers actively oppose having them, or just not have any concrete plans to add them?
- kibwen 13y ago
  Merely lukewarm, I think. There are simply much higher priorities to focus on at the moment. Who knows what Rust 2.0 might hold!
  - pnathan 13y ago
    I've always found the profusion of infix operators in Haskell to be heinously confusing, and seriously degrades readability and usability of libraries.limits on the o
    - Dewie 13y ago
      The problems I see with infix operators are: - It's not necessarily obvious what is an infix operator - Precedence and associativity I think Haskell has solved the first one: with all non-alphanumeric symbols in expressions being infix operators, and likewise for alphanumeric functions written with backticks. But precedence and associativity is not obvious, since that is something that you can customize. I think that user-defined infix operators with some severe limits on choosing precedence and associativity is a good compromise (many use backticks on functions in Haskell, and that has a default precedence).
Arelius 13y ago
That's great. Really, the only case in C++ I want operator overloading, is to implement standard math operators on custom types, like Vector3s, Matrices, and Bignums.
- humanrebar 13y ago
  Assuming you use smart pointers, you'll want overloading for pointer operators as well, even if you're not implementing the smart pointers yourself.
  - Arelius 13y ago
    I'm not however sure that applies to Rust. And frankly I care a lot less about the pointer operators for smart pointers. Any old accessor is decent, and I find the overloaded pointer operators sometimes confusing. At the very least it's not quite as obvious as it is for math operators.

mcguire 13y ago

There is this: http://maniagnosis.crsr.net/2013/04/operator-overloading-in-rust.html http://maniagnosis.crsr.net/2013/04/operator-overloading-in-... I think a current version should still be similar, although I haven't had a chance to take a look at the code for 0.9. I also notice that I forgot to update that with the double-dispatch approach.