Phil Deets wrote:
On Wed, 09 Dec 2009 02:40:44 -0500, Phil Deets <[email protected]> wrote:
On Tue, 08 Dec 2009 22:26:10 -0500, Don <[email protected]> wrote:
Phil Deets wrote:
On Tue, 08 Dec 2009 12:42:33 -0500, Bill Baxter <[email protected]>
wrote:
On Tue, Dec 8, 2009 at 2:32 AM, Don <[email protected]> wrote:
[snip]
* If both x and y are integers, and y > 0, x^^y is equivalent to
{ auto u = x; foreach(i; 1..y) { u *= x; } return u; }
* If both x and y are integers, and y < 0, an integer divide error
occurs,
regardless of the value of x. This error is detected at compile
time, if
possible.
Can you explain why you think that's necessary? Seems like going too
far towards a nanny compiler for no particularly good reason.
The fact that 2^^-1 isn't particularly useful doesn't make it
particularly error prone. No more so than integer division when the
person meant floating point division. I just find it unexpected that
a language would single out exponentiation for this kind of treatment.
I was also wondering about this. If it can't be detected at compile
time, is the result 0?
No, it's a compile-time error.
It can't be a compile-time error if it can't be detected at compile
time like I said in my question. In the code
Sorry. I misread that. I wrote that at 3am.
2^^SomeFunctionFromACModuleThatReturnsInt();
the compiler can't know whether the exponent will be positive or
negative. When the code runs and a negative result is returned, will
the result be zero?
Maybe you meant, if you can't prove it's positive, it's an error. If so,
I would suggest requiring an unsigned type.
Read the proposal. It's a runtime divide error.
