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

Brendan Eich brendan at
Fri Aug 17 11:54:53 PDT 2012

Andreas Rossberg wrote:
> On 16 August 2012 23:47, Brendan Eich<brendan at>  wrote:
>> Andreas Rossberg wrote:
>>> On 16 August 2012 00:35, Rick Waldron<waldron.rick at>   wrote:
>>>> It would be far worse to have a different type of value as a return,
>>>> right?
>>> Actually, no. It is far better to have something that produces failure
>>> as immediately and as reliably as possible when used improperly.
>>> Sentinel values are a prominent anti-pattern.
>> Spoken like a true ML'er :-P.
> Well, in the pre-ML world I've been brought up in, it was still
> considered good software engineering practice, independent of
> language, static or dynamic (and ML has its share of violations, too
> ;) ).

When "failure" means failure, I agree.

>> -1 as an out-of-band (for non-negative indexes) return code is actually
>> easier to test
> Why is it easier to compare against constants -1, NaN, or "" than to,
> say, null or undefined? And if so, wouldn't that be something that
> might be worth correcting? Question mark operator, anyone?
>    let index  = s.find(...)
>    if (?index) {   // equivalent to index !== undefined
>       ...
>    } else {
>      // err...
>    }

We've toyed with that operator, but my point was that you don't need an 
if of that kind of you can write a combined index test, e.g. in a cheezy 
split-like example:

js> var s = "a b c "
js> var a = []
js> var i, j = -1
js> while ((i = s.indexOf(' ', j+1)) >= 0) { a.push(s.slice(j+1, i)); j 
= i; }
js> a
["a", "b", "c"]

In this case, undefined as indexOf sentinel value would work too because 
it converts to NaN -- but null would not work (it converts to 0). Using 
an "in-band OOB " (for number type) sentinel wins.

> Ultimately, it boils down to careful API design. For some operations
> there is a useful neutral value to return in edge cases. For others,
> there isn't.

I hope it's clear from my examples and particular arguments that I agree!

>> Then the conciseness and clarity of the test matters, and typeof
>> rv != "number"is the wrong tool compared to rv<  0.
> I agree that typeof is the wrong tool, but rv !== undefined seems
> reasonable to me.

See above. Relying on undefined -> NaN could work for numeric contexts, 
but (the charAt example) preferring undefined to "" is likelier to make 
"DuckPigundefinedCow" than "DuckPigCow", ceteris paribus :-P.


More information about the es-discuss mailing list