Consistency in The Negative Result Values Through Expansion of null's Role

Norbert Lindenberg ecmascript at
Wed Aug 15 21:51:05 PDT 2012

On Aug 15, 2012, at 15:35 , Rick Waldron wrote:

> On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen <erik.reppen at> wrote:
>> * 'wombat'.charAt(20); //returns an empty string, but that's a concrete value whereas 'wombat'[20] returns undefined
> For the same reason indexOf always returns a number, charAt always returns a string.
> "wombat"[20] will dereference the string at an index that doesn't exist, which means it's undefined.

I think undefined would have been a fine return value for 'wombat'.charAt(20) - you asked for something that's not there. The expected return value in the "it's there" case is a one-code-unit string, so an empty string doesn't meet expectations anyway.

>> * NaN - It can tell you a lot about what kind of thing went wrong but given it's not-equal-to-itself nature it can be a nasty return value when unexpected. For instance, 'wombat'.charCodeAt(20) returns NaN. How does this makes sense in the context of JavaScript? Yes, I'm trying to get a number but from what I would assume (in complete ignorance of unicode evaluation at the lower level) is some sort of look-up table. I'm not trying to divide 'a' by 2, parseInt('a') or get the square root of a negative number.

In this case NaN is clearly wrong, because what the caller expects is a code unit, an integer between 0 and 0xFFFF. You have to check for NaN just like you have to check for undefined, but undefined would have been the normal JavaScript result for "nothing there".

It's too late to fix charCodeAt, but for the new codePointAt I'm proposing undefined as the "nothing there" result.


More information about the es-discuss mailing list