Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obvious (and are actually
where a major benefit of an operator can come in).
Using the normal promotion rules, 10^^2 is an integer. The range
checking already present in D2 could be extended so that the compiler
knows it'll even fit in a byte. This gets rid of one of the classic
annoyances of C pow: int x = pow(2, 10); doesn't compile without a
cast.
But the difficult question is, what's the type of 10^^-2 ? Should it
be an error? (since the result, 0.01, is not representable as an
integer). Should it return zero? (just as 1/2 doesn't return 0.5).
For an example of these semantics, see
http://www.tcl.tk/cgi-bin/tct/tip/123.html).
Or should it return a double?
Or should 10^^2 also be a double, but implicitly castable to byte
because of the range checking rules?
I currently favour making it an error, so that the normal promotion
rules apply. It seems reasonable to me to require a cast to floating
point in there somewhere.
This is analagous to the similar case f ^^ 0.1; where f is known to
be negative. This gives a complex result, creating a run-time error
(returns a NaN). But, there's no standard error and no NaNs for
integer underflow.
One could also make int ^^ uint defined (returning an int), but not
int ^^ int. Again thanks to range checking, int ^^ uint ^^ uint would
work, because although uint ^^ uint is an int, it's known to be
positive, so would implicitly convert to int. But would making int ^^
int illegal, make it too much of an annoying special case?
I strongly suspect that x^^y, where x and y are integers, and the
value of y is not known at compile time, is an extremely rare operation.
Also, should int^^uint generate some kind of overflow error? Although
other arithmeic integer operators don't, it's fantastically easy to
hit an overflow with x^^y. Unless x is 1, y must be tiny (< 64 to
avoid overflowing a ulong).
Nice analysis. IMHO this should lead us to reconsider the necessity of
"^^" in the first place. It seems to be adding too little real value
compared to the complexity of defining it.
Andrei
It adds a lot of value to the ones that actually use it, even though you
may not be one of them. Exponentiation is extremely common in numerics.
Here are some statistics for you: A Google code search (see below) for
FORTRAN code using the power operator **, which until recently didn't
have a D equivalent, yields roughly 56100 results.
A search for the FORTRAN equivalents of << yield 400 results for ILS()
and 276 results for LSHIFT(). Yet, left shift apparently deserves a
place in D.
FORTRAN also has the ISHFT() shift function, which gives about 2000
results on Google. Still way less than for **.
(I've used http://www.google.com/codesearch, with the following search
strings for **, ILS and LSHIFT, respectively:
[0-9a-zA-Z)]\*\*[0-9a-zA-Z(] lang:fortran
ils\([0-9a-zA-Z] lang:fortran
lshift\([0-9a-zA-Z] lang:fortran
ishft\([0-9a-zA-Z] lang:fortran
-Lars
