Support a very basic form of operator overloading

[marijnh]

(RFC)

We could add interfaces core::num and core::deref, with the first implementing methods add, sub, mult, div, rem, neg, and probably a few more, and the second only deref. The compiler can then resolve operators +, -, *, /, %, and [x] on types that are not built-in numerics or vectors as if they were calls to the corresponding method (1 + 1 => 1.add(1)), and numeric-style and sequence-style user types can implement these interface to allow the operators to be applied to them.

This is not the most elegant solution (1 + 1 is more like add(1, 1) than 1.add(1)), but it would give us operator overloading on the short term, without first needing a lot of extra interface features.

We will need some kind of support for a 'self type' in interface declarations to be able to say that add takes an returns a value of the type that the interface was specialized on, which is not currently expressable.

[nikomatsakis]

I am a big fan of this general idea. I think we should use generic types where it makes sense: in particular the deref interface should be something like fn get(k: K) -> V, so that it works with maps. But it makes sense even for operators like + and * if you plan to stretch their numeric meaning a bit:

inter mul<R, V> {
    fn mul(r: R) -> V;
}

would allow

impl of mul<int, str> for str {
    fn mul(times: int) -> str {
        let base = self;
        uint::range(1, times) {|| base += self; }
    }
}

you could then write " "*15, as you can in Python. The danger is that it opens the door to implicit numeric coercions, but at least users have to write those themselves rather than us doing it for them.

However, I think the fact that one must implement all core:num or none is not so appealing. I'd rather have the individual operators broken out into individual interfaces and then a core:num group interface. I can certainly think of things that are addable but not subtractable (strings and vectors) and so forth.

I guess it depends a bit on whether we intend for these operators to be used strictly for their analogous purposes or whether we intend to allow nicer notation for a few other cases. I say intend because people will use them for other things beyond numerics and lists whatever we do, but I guess we can make it more painful for them if we want to.

[marijnh]

I can certainly think of things that are addable but not subtractable (strings and vectors) and so forth.

I guess this is a matter of taste. I like operators to mean one thing and only one thing -- I think Haskell's Num class gets it right. But since Rust is already abusing + for vector concatenation, I'm okay with supporting separate interfaces and allowing people to do more free-form things.

[kevina]

This issue sorta relates to Issue #535.

[kevina]

Actually I was reading the summary for 535 way too fast, it was about overloading in general and not operator overloading.

In any case, I believe that if Rust is going to support ad-hoc operator overloading, it should also allow defining new operators. Otherwise the existing operators will be abused to do things that have nothing to do with the original operator's meaning; for example the << operator in C++.