Custom operators

[iluuu1994]

Original issue

There's some controversy over custom operators and them being overused in cases that don't really make sense and how they can be more confusing than helpful. I personally love them and think that they, when used wisely, can really make certain APIs much more appealing.

Rust allows you to overload a few basic operators using traits defined in the standard library. That's great but you're very limited to what you can actually do with them.

I'd like to point you to Swift here. They have solved this problem rather nicely.
You can implement operator functions and define some properties on them, like:

• Precedence
• Left or right asociativity
• Prefix, infix, or postfix

Here's how Rust could look defining a custom null coalescing operator:

op ?? {
    assoc: left,
    prec: 100,
}

infx fn ??<T>(l: Option<T>, r: T) -> T {
    match l {
        Some(s) => s,
        None => r,
    }
}

I haven't given too much thought to the example above, it's probably suboptimal and doesn't play too well with the existing syntax. So it's just an example.

Basically, I'm interested in hearing what other people would think of more generic operator overloading functionality in Rust.

As I said before:

Btw Rust is super awesome :D 🤘

Fantastic work guys

[glaebhoerl]

It would make sense to title this issue "custom operators" or "user-defined operators" or something of that nature instead of "operator overloading".

[cameron-martin]

Is this being considered at all?

[KalitaAlexey]

@cameron-martin Could you provide example when you need custom operator and simple function couldn't help you? I am against custom operators because it is complex.

[Centril]

The main problem with custom operators, which is quickly experienced if you've written any haskell is that the symbols included in the operator identifier does not usually inform the meaning of what the operator does, unless it is picked very judiciously. Standard operators used in mathematics are so often used that everyone knows their meaning instantly. A function which has its identifier written in English conveys the meaning of what it does much more clearly.

Instead of adding custom operators, another beneficial idea would be to allow infix calls to functions like so:

a `dot` b

to convey scalar product of two vectors a and b.

Which is converted to

a.dot( b )

or, depending on the function:

dot( a, b )

This also has the benefit of being similar to another language (haskell).

[ticki]

I have a strong dislike for arbitrary user-defined operators. Essentially, you end up with each library providing an entirely different language. People quickly abuse this kind of stuff because it "seems nice at first", but it gets a mess for the library user. Parsing it is pretty much impossible too.

It is worth noting that Rust already got operator overloading, which covers the majority of cases.

Fantastic work guys

... and gals.

[alilleybrinker]

As an example of what sort of excess can occur with user-defined operators, look at Haskell's Lens library. It's a fantastically useful library with an complex and opaque sub-language of special operators in it. Attempting to read Lens code without the operator reference open is a task only for the library's most experienced users. Rust already has complex syntax. I don't think more complexity is a good idea.

The notion of infix operators is interesting, though I am not sure how much they get you over methods. My general instinct says to leave the syntactical complexity alone unless you have a good reason.

[davesque]

I'll have to put in my vote against this idea. Building on @AndrewBrinker's comment, I feel Haskell has demonstrated exactly why this kind of feature usually doesn't belong in a language. The idiom of custom operator use in Haskell is a barrier to entry, hands down. I've often wondered to myself what a language with exactly the same features as Haskell (but minus the annoying and opaque syntax) would look like and if it wouldn't gain broader acceptance. If this kind of thing ever does find its way into Rust, it would have to be in the most sparing and sober way possible.

[ticki]

Haskell went through so much pain, with the only advantage of having a mostly useless feature. In fact, it tend to be abused and makes everything a mess.

The infix function is more sane, but I'm not sure if it is needed enough to be worth adding.

[burdges]

I think custom syntax can help with mathematics, well crypto crates love #![allow(non_snake_case)], but custom operators rarely help much.

Instead I'd look more towards the units crate which uses wrapper structs heavily. I think more important tools include:

1. It'd rock if side effects could be exposed well enough by a bignum library that DivRem or similar can be optimized correctly from separate / and % calls. You do not want those all those pretty binary operators killing performance!

2. We do not make up many so many operators in mathematics, but instead dance between several different objects in which we envision an element living. Arguably that perception shift corresponds best to applying wrapper structs that change how existing operators apply. I'd think painless delegation would let map change these wrapper structs more easily.

3. A good REPL would let people experience using Rust in a more dynamic way.

[davesque]

@ticki @Centril While I don't like custom operators, I actually agree that infix invocation could be useful. I've even enjoyed using languages that also have prefix and suffix invocation (as with Haskell's $ operator and Mathematica's @ and // operators). But I think it would need to be an experimental feature and would need to go through an extensive trial period to prove that abuse of it would not become idiomatic. Since Rust (IMHO) already has a lot of syntax, it's a bit risky introducing features like this.

[glaebhoerl]

Method syntax is infix invocation.

[iluuu1994]

I'm closing this RFC as most people seem to be aganist this idea. I admit that in general the usefulness of this feature is limited. I was writing parser combinators which is one of the few times custom operators could be useful.