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