Then sorry, I misunderstood your position.
Rust Devs have very strict policy about which operators could be added to the language.
The reason must be very-very promising. And adding "logical xor" operator does not look promising at all. That was my point.
But adding powering operator could be promising because most languages, which inspires Rust has such operator. And such action as powering is common for most people who learn math at school.
Another (slight) advantage of a dedicated operator would be not having to care about powi versus powf.
I stand on my original proposal for using ** as an operator. I don't think ^^ is suitable for a power operator, since it resembles Knuth's up arrow notation (↑↑). My proposal is to use the ** operator, for the reasons mentioned above by me and others, most notable the fact that programming languages that have a power operator tend to use ** and that it would be good to have a dedicated operator for exponentiation.
Some people have expressed their concerns that ** could cause issues with code where that syntax exists already, with the second * dereferencing an integer reference and the first one performing a multiplication. However, this change, although breaking, I don't believe it is a major one and could occur over the course of a Rust edition. In that case, if ** were to take precedence over both the * deref and the * multiplication operator, migration could be as easy as that. Of course, that is just one possible solution to the problem, but what I wanna say is that there are ways around it.
We could also just make a Pow<Exp> trait without an operator. Would still help with type inference and having a method for all number types
Choosing an operator could take some time (what symbols to use, backwards compatibility for cases such as this, but putting all the pow methods in their own trait would probably be a faster procedure. What would be the best way to suggest this change? A separate post here on Rust Internals? A RFC?
The normal way would be to file an ACP
Maybe try to make an impl of the trait on your own first so you can directly show the difficulty and behavior when proposing it
A trait would do this regardless of an operator.
Optimally a lot of methods that exist for various numeric types (such as trailing_zeros) would be parts of traits, so that they can be used directly in generic code.
We already have all of this, just not in std.
Adding the Pow trait in the Rust Core Library could pave the way for an exponentiation operator.
I feel like this would be very dangerous. pow itself is a very niche function. So i would assume that a ** found in a file is more likely actually meant do be a dereference and multiply, but the author forgot that cargo fmt no longer inserts the missing space.
So we'd need to have a lint use_of_pow_op. Wich would be used in more crates than the pow operator
Also can anyone actuality give an example of a language with the ** operatior that also has * as a dereference operator.
Neither JavaScript, Python nor Haskell have a dereference operator.
I just thought about cargo fmt again. We now have format editions, but these must be manually chosen when using rustfmt directly. This would mean that accidentally using the wrong style edition when formatting would change the semantics of the program because a**b is replaced with a * *b in the current edition .
Python does have f(*args, **kwargs). But I believe these only work inside function calls as unary operators.
Python *expr is allowed in expression lists, including set, list, and tuple constructors, and **expr is also allowed in dictionaries. These can't be confused for a binary op though.
Hopefully, ** is not the only option. We could define ^^ for example for powering.
It looks very human-friendly, a lot of people write 2^8 or 3^5 to represent powering.
And 2 ^^ 8 or 3 ^^ 5 looks as good as expected.
And hopefully, wrong writing expression 2 ^ ^ 8 always call the error during compilation, because xor of xor has no meaning.
I found an example of using ^^ in popular languages:
For example, Haskell has 2 similar functions-operators in Prelude:
-- raise a number to a non-negative integral power
(^) :: (Num a, Integral b) => a -> b -> a -- infixr 8
-- raise a number to an integral power
(^^) :: (Fractional a, Integral b) => a -> b -> a -- infixr 8
So, it is not so "esoteric" to use ^^ for powering.
As mentioned in another comment, ^^ looks a bit too much like tetration (as in, repeated exponentiation, using Knuth’s arrow notation). Though I guess in practice I doubt many people would assume there’s an operator for something as obscure as that.
While I believe that ^^ might remind a couple of people of tetration, I honestly doubt there is even a single program or algorithm out there that actively uses this kind of operation. I still root for **, but considering the potential issues eith it, I believe ^^ would be a good alternative.
95% of people who use Rust don't know about "tetration" and how it looks. And by the way, it looks absolutely differently: ↑↑, not at all close to ^^.
And even who knew about such operation, they 99.999999% never ever use it in Rust.
So, why are we talking about "tetration"?
Since the up-arrow is used identically to the caret (
^), tetration may be written as (^^); convenient for ASCII.
Doesn't make it the only interpretation, but it's an interpretation.
Tetration is a pretty uncommon mathematical operation. Wikipedia lists only 1 application, while in a Quora thread, one of the answers suggests it doesn't have an application even in theoretical mathematics. Apart from that, I would be surprised if there is a (non-esoteric) programming language out there that has a tetration operator. Nevertheless, if ^^ can't be used, we could resort to **, which unfortunately suffers from the problems previously discussed.