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