In that case, we would have to reserve the pow keyword. Since Rust 2015, only 2 keywords, try and gen have been reserved. There are at least 3 other candidates and I believe that the last thing we want as a language is reserving another keyword
As of writing this answer, 37 people have voted on whether or not Rust needs an exponentiation operator, and even though the sample size is a bit small in my opinion, the near 40% difference between the results (68%/25 votes No - 32%/12 votes Yes) seem to indicate that with a two-thirds majority, Rust users don't think that the language should have an exponentiation operator. Given that, I am wondering whether or not this discussion should be continued or be closed
IRLO regulars aren't a representative sample. I don't have the spare cycles to do it myself but it might be a good idea to, at least, run the same poll on users.rust-lang.org before concluding that Rust users in general don't want this feature.
4 Likes
I think it's worth reiterating, here, that a Pow trait would be worth doing whether or not it ever has a corresponding operator.
I'd love to see an ACP for a Pow trait.
6 Likes
I think such traits could be useful for a lot more of the integer and floating point inherent functions. This would make it easier for crates that define numeric types to integrate well with the overall ecosystem.
num-traits — Rust math library // Lib.rs is prior art here (it has a pow trait as well).
From what I understand, that advantage would be due to type inference, right?
I just created an account over there but I don't have the required trust level to create a poll. If someone else could do that and link this discussion, that would be really helpful.
^^ will also be used in cpp26 for reflection. Reflection for C++26
3 Likes
I'm not a fan of this proposal of having a dedicated operator for exponentiation.
First, because Rust doesn't seem to be a language optimized for maths notation terseness. For example, when dealing with numbers that can go big (as is the case when doing pow()), it's very common to have to use .checked_add() or similar methods instead of the infinitely more readable +. And that's fine. We're OK with trading some terseness for correctness / explicitness.
And secondly, because it sets a precedent for then adding more special operators for other functions. For example, if pow() has its own operator a ** b, why shouldn't the "real modulo" operation (what Rust calls rem_euclid()) also have its own a %% b? Or an operator to get the greatest common divisor between two numbers (an operation i'm surprised the standard library doesn't provide)? Or an absolute value, |a|, or floor, ⌊a⌋, or square root, √a, operator?
Yeah, i know that argument sound like a slippery slope fallacy. But, of those operations i mentioned, i've actually used a couple of them much more frequently than pow() —"real modulo" being the most prominent example. So, if the main argument for adding an exponentiation operator is that it'd be useful in some contexts, we should be prepared to have that same argument used for inclusion of other operators in other contexts too.
I personally am not totally against the idea of having more operators, or even user-defined operators alla Haskell. I proposed adding these exponentiation and real modulo operators to CoffeeScript many winters ago. But CoffeeScript is (was?) a very high-level and "cute" programming language, where it makes sense to have this kind of syntactic sugar. For Rust, i don't see these being a great fit TBH.
Maybe if we had some more tooling and QOL around operators, to make them more discoverable and usable —think autocomplete, auto-conversion of .pow() to **, allowing "go to definition" when over the **, always having a "named" function counterpart, etc— then i think adding more specialized or even user-defined operators would be more appealing overall 
6 Likes
I have used square root way more than wither pow or real modulo. I don't think any of them should be added as operators.
Depending on what code you write I expect that you will have your own favourite "this should be an operator". I would prefer sticking to only the basics: I have read some Haskell, and the proliferation of unreadable operators is certainly one of my least favourite parts.
I think the current set of mathematical operators is fairly well rounded in Rust. Sure this means having to write out wrapping_add a bunch, but I value that explictness (wrapping is far more common than checked in my experience, but again: I don't expect this to be universal).
1 Like
Nevertheless, I believe that a poll should take place at the Rust user forum before we can safely draw any conclusions about the community
Note that a poll on the users forum is not exactly representative of anything either. Most regulars will be experienced users that are so much into Rust that they hang out on forums, a similar type of user that can be found here.
2 Likes
In that case, if we consider the poll made here representative, there's nothing more to say about the exponentiation operator. That leaves only the question of whether or not Rust should have a Pow trait.
Regardless of whether or not Rust were to add an exponentiation operator, should there be a Pow trait?
- No
- Yes
0
voters
Can you please add an abstention option? I don't particularly want a Pow trait, but I don't want to say "no, it can't happen" (a trait I can ignore; an operator much less so) and I also don't want to signal that I necessarily believe it is worth spending time on it at the expense of other things.
6 Likes
It seems like I can't edit a poll after the first 5 minutes. To those that share the same opinion as you, I would recommend them to simply abstain. In the end, for a poll to be taken into account, it should have at least some reasonable number of voters.
I'd like to point out that Python, Javascript, and even Haskell have REPLs that allow using them as calculators. For this usecase, having a pow operator is useful.
x ** y is not that better than x.pow(y) though. Especially when you need to parenthesis everything anyway, due to operator precedence.
3 Likes
I mean operator isn't settled, but if it was why wouldn't ** take precedence over other operators?
I've opened an ACP over at Github about a Pow trait.