Pow operator precedence
Timon Gehr
timon.gehr at gmx.ch
Fri Jan 13 13:06:02 PST 2012
On 01/13/2012 07:18 PM, Manu wrote:
> On 13 January 2012 19:41, Matej Nanut <matejnanut at gmail.com
> <mailto:matejnanut at gmail.com>> wrote:
>
> I feel it should be left as is: it'll be ambiguous either way and
> why mess
> with how it's in mathematics? If anyone feels uncomfortable using it,
> just use std.math.pow. Many other languages don't have this operator so
> people coming from them won't know it exists anyway (like me until this
> post).
>
>
> Expecting all people who may be uncomfortable with it to use pow()
> doesn't help those who have to read others code containing the operator.
They surely can spend the 2 seconds worth of effort to become
comfortable with it. This is an exceedingly trivial issue, and D has
adapted a common convention.
> It's NOT like it is in mathematics, there is no 'operator' in
> mathematics (maths uses a superscript, which APPEARS to be a unary
> operation).
If an operation has two parameters, then it is a binary operation.
> When using the operator, with spaces on either side, it
> looks like (and is) a binary operator.
^ commonly means superscript. It simply cannot be argued that ^^ does
not resemble ^ a lot. (no matter how many spaces anyone puts anywhere.)
> I think it's reasonable for any experienced programmer to expect that
> any binary operator will have a lower precedence than a unary operator.
It is reasonable for any 'experienced programmer' to be familiar with
some language/calculator that has an exponentiation operator.
Furthermore, I bet there are many 'experienced programmers' who would
actually be surprised that -a*b is parsed as (-a)*b instead of -(a*b).
> What I wonder is why this operator is necessary at all?
Few handy language features are strictly 'necessary'. Having ^^ as a
built-in means that the compiler can optimize it for common small
constant exponents, like 2 or 3.
> With this ambiguity, it harms the readability, not improves it :/
There is no ambiguity. And yes, it improves readability:
sqrt((x1-x2)^^2+(y1-y2)^^2);
is better than
sqrt(pow(x1-x2,2)+pow(y1-y2,2));
or
sqrt((x1-x2)*(x1-x2)+(y1-y2)*(y1-y2));
There is no contest.
More information about the Digitalmars-d
mailing list