Consistency in The Negative Result Values Through Expansion of null's Role
brendan at mozilla.org
Thu Aug 16 14:24:36 PDT 2012
Norbert Lindenberg wrote:
> On Aug 15, 2012, at 15:35 , Rick Waldron wrote:
>> On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen<erik.reppen at gmail.com> wrote:
>>> * 'wombat'.charAt(20); //returns an empty string, but that's a concrete value whereas 'wombat' returns undefined
>> For the same reason indexOf always returns a number, charAt always returns a string.
>> "wombat" 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.
But you are requiring all clients who take the in-band return value to
be string and concatenate it, e.g., to check and avoid cat'ing "undefined".
Having a monotyped return value is common in scripting languages and it
avoids requiring callers to write a refutable match. Irrefutable FTW again!
You don't always have to check for NaN, again. Code that is testing for
a certain code unit using === or even == (because the monotyped return
value ensures number) will get guaranteed mismatch with NaN.
It's true that undefined converts ToNumber resulting in NaN, so this
case is a bit better than the first one -- no string concatenation issue.
> It's too late to fix charCodeAt, but for the new codePointAt I'm proposing undefined as the "nothing there" result.
Why is undefined better than NaN? Aesthetics about "nothing there" are
not really relevant. You should make a case based on common code
patterns and what happens if there is no extra out-of-band return value
check (which there need not be in many cases, e.g. === or ==).
More information about the es-discuss