On Mon, Aug 15, 2011 at 10:29 AM, Israel Hilerio <isra...@microsoft.com> wrote: > On Sunday, August 14, 2011 4:09 PM, Aryeh Gregor wrote: >> On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> > Yup. Though I think WebIDL will take care of the handling for when the >> > author specifies a negative value. I.e. WebIDL will specify what >> > exception to throw, so we don't need to. Similar to how WebIDL >> > specifies what exception to throw if the author specifies too few >> > parameters, or parameters of the wrong type. >> >> It doesn't throw an exception -- the input is wrapped. It basically calls >> the >> ToUInt32 algorithm from ECMAScript: >> >> http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long >> >> This behavior is apparently needed for compat, or so I was told when I >> complained that it's ridiculous to treat JS longs like C. It does have the >> one >> (arguable) advantage that authors can use -1 for "maximum allowed value". >> >> But anyway, yes: if your IDL says unsigned, then your algorithm can't define >> behavior for what happens when the input is negative, because WebIDL will >> ensure the algorithm never sees a value outside the allowed range. If you >> want special behavior for negative values, you have to use a regular long. >> > > I like Areyh's suggestion. What if we were to keep the parameter as a long > and specify in the spec that zero and negative values will not advance the > cursor in any direction. We could add something like this: > "If the count value is less than or equal to zero the iteration will not take > place." > After thinking about this some more, I like this better than having the > unexpected side effects of passing a negative number to a unsigned long > parameter. > > Jonas, what do you think?
Hmm.. Yeah, I suspect that is the better behavior here. We should probably also throw if the number is 0. / Jonas