More fun with undefined

T.J. Crowder tj at
Fri Jun 15 07:56:01 PDT 2012

On 15 June 2012 15:34, Aymeric Vitte <vitteaymeric at> wrote:

>  I am not talking about defining implicit properties or such things,
> neither having undeclared stuff looking declared, but just changing the
> behavior of retrieving a property when base is undefined, which will then
> be undefined.
> If am I reading correctly the specs, doing this change will work for
> a.b.c.d, because undefined is returned first and nothing is set anywhere,
> unless I am wrong :
> console.log(a); //reference error
> var a;//undefined
> console.log(a.b);//reference error
> will become :
> console.log(a); //undefined
> var a;//undefined
> console.log(a.b);//undefined

So you're proposing two changes:

1. Let getting an unresolvable symbol evaluate to `undefined`, rather than
causing a ReferenceError (which requires changing GetValue, at least), and

2. Allow accessing a property of `undefined` to evaluate to `undefined`,
rather than causing a TypeError (which requires changing either how
property accessors work, or changing the definition of CheckObjectCoercible
so that it coerces undefined into {} or some such).

You'd need both of them to make `a.b` "work" (evaluate to undefined rather
than throwing) where `a` is unresolvable, #1 to prevent the ReferenceError
on `a`, and #2 to prevent the TypeError when trying to retrieve `b` from

Either would be a big, breaking change on its own.

Re #1: I wouldn't be in favor, FWIW. I think it's much better to have a
ReferenceError on an unresolvable symbol than have it treated as though it
were resolved, but had the value `undefined`. Again, the feature of strict
mode where assigning to unresolvable symbols stopped creating global
variables was a Good Thing(tm). :-) To me this is in the same vein as the
old behavior there was. If I try to read the value of an unresolvable
symbol, I want the proactive notification I get from the ReferenceError; I
don't want to try to find the subtle bug the implicit `undefined` helps
hide (in my view).

Re #2: I wouldn't be in favor, FWIW. Consider:

function foo(o) {

Currently, the call to `foo` throws, because I'm not passing in any
argument, but the code dereferences `o` without testing first. This is
clearly a bug in the call to `foo`. Currently, I get proactive notification
of that bug (via the TypeError). With change #2, the code would try to log
undefined instead -- a much harder, more subtle bug to try to find and fix.

Yes, the current behavior wrt reading from unresolvable references vs.
reading from undefined properties can be viewed, from some angles, as
inconsistent. But it's very thoroughly ingrained in the language, and I
don't see a strong argument for change.

Just my $0.02.


-- T.J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list