Pow operator precedence

Matej Nanut matejnanut at gmail.com
Fri Jan 13 10:46:28 PST 2012


Oh, yeah, my bad. I've been at uni for too long: seeing subscripts as "^a"...
I agree that an operator for this is unnecessary though. At least I have never
felt the need to write "pow(,)" quicker than 6 symbols.

On another note, Octave (and I guess Matlab as well?) use D's precedence
for the pow operator. Bearophile stated earlier that Python does too. Those
seem like quite large audiences. I'm not saying agreeing with the masses
is the choice here, but if a mathematical environment sees it as fit, and
since as far as I'm concerned there's still no reason to prefer one over the
other, it should be either deprecated or left alone.

It will remain ambiguous to someone at some point, no matter how it's
defined. Part of learning the language though.

On 13 January 2012 19:18, Manu <turkeyman at gmail.com> wrote:
> On 13 January 2012 19:41, Matej Nanut <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.
> 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). When
> using the operator, with spaces on either side, it looks like (and is) a
> binary operator.
> I think it's reasonable for any experienced programmer to expect that any
> binary operator will have a lower precedence than a unary operator.
> What I wonder is why this operator is necessary at all? With this ambiguity,
> it harms the readability, not improves it :/


More information about the Digitalmars-d mailing list