Semantics of ^^

Don nospam at nospam.com
Tue Dec 8 23:51:38 PST 2009


Phil Deets wrote:
> 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
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.



More information about the Digitalmars-d mailing list