Andrei Alexandrescu wrote:
I've tested the typing rules for ^^ and they seem wanting. One painful
example:
int a2 = 3, b2 = -2;
writeln(typeof(a2 ^^ b2).stringof);
writeln(a2 ^^ b2);
The program writes:
int
zsh: floating point exception ./test.d
Ouch. Here's what I suggest:
====
The type of the power expression is: @uint@ if both @base@ and @exp@
have unsigned types less than @ulong@; @int@ if @base@ is a signed
integer less than @long@ and @exp@ is an unsigned type less than
@ulong@; @ulong@ if both @base@ and @exp@ have unsigned types and at
least one is @ulong@; @long@ if @base@ is @long@ and @exp@ is an
unsigned type; and @double@ for all other combinations of integral
@base@ and @e...@. If at least one of the operands has a floating point
type, the result type is the largest participating floating point
type.
====
Makes sense?
The problem with this rule is (if I understand correctly) that a2 ^^ 2
has type of double.
It's crucial that x ^^ 2 has the same type as x. The annoying thing is
that positive literal integers are of type int.
The existing behaviour is intentional (it's an intentionally generated
divide error), although the error should be moved to compile time.
The idea is that int ^^ int should be illegal. Only int ^^ uint should
be valid. The code above would therefore generate a compile-time error
for any circumstance where it is possible for the exponent to be
negative. Range-checking isn't yet fully implemented though. Currently
it only gives an error if the value of y is known at compile-time.
The intended behaviour is:
-1 ^^ exp where exp is an integer is transformed into (exp & 1)? -1 : 1;
1 ^^ exp where exp is an integer is transformed into (exp, 1).
Otherwise, if both base and exp are integral types, and exp cannot be
implicitly converted to an unsigned, a compile time error occurs.
Whenever base ^^ exp is defined, typeof(base ^^ exp) is always the same
as typeof(base * exp).
