Semantics of ^^

[Phil Deets]

On Wed, 09 Dec 2009 02:40:44 -0500, Phil Deets <pjdeets2 at gmail.com> wrote:

> On Tue, 08 Dec 2009 22:26:10 -0500, Don <nospam at nospam.com> wrote:
>
>> Phil Deets wrote:
>>> On Tue, 08 Dec 2009 12:42:33 -0500, Bill Baxter <wbaxter at gmail.com>  
>>> wrote:
>>>
>>>> On Tue, Dec 8, 2009 at 2:32 AM, Don <nospam at nospam.com> 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
>
> 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.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/