barrier dimension, default dimension

David Herman dherman at mozilla.com
Fri Dec 28 11:30:06 PST 2012


Andreas pointed out [1] that the question of defaulting to undefined vs uninitialized is orthogonal to the question of read-barrier vs read-write barrier:

> Even with TDZ-RBA you can have that meaning for "let x" (and that semantics would be closest to 'var'). What TDZ-RBA gives you, then, is the possibility to also assign to x _before_ the declaration.

My characterization unnecessarily combined these two orthogonal concerns. So we have two dimensions of TDZ alternatives:

Barrier dimension:

* RBA: There's a read barrier but assignments are allowed even before executing the let.
* UBI: There's a read/write barrier; neither references nor assignments are allowed before executing the let.

Default dimension:

* UNINIT: An initializer-less let statement leaves the variable uninitialized.
* UNDEF: An initializer-less let statement sets the variable to undefined (if it's still uninitialized).

So we already agree that TDZ-RBA-UNINIT is a non-starter, and TDZ-UBI-UNINIT is incoherent (there'd be no way to use the variable!). But that does leave this other semantics, TDZ-RBA-UNDEF.

> But anyway, I think we agree that this is not a desirable semantics, so it doesn't really matter.

All last night I was chewing on this concept of an illegal assignment, and it's bugging me. How would you explain this error to a programmer?

    {
        initialize();
        let x;
        function initialize() {
            x = f(); // error: x is uninitialized
        }
    }

This looks an awful lot like it's saying "you can't assign to x because x hasn't been assigned to." To understand the distinction, programmers have to learn the rule that only the syntactic initializer is allowed to initialize the variable.

Put differently, a write barrier strikes me as really odd.

Andreas, can you explain why you dismiss TDZ-RBA-UNDEF as a viable option? The bug that motivates all the arguments you've made is read-before-initialization, not write-before-initialization.

Dave

[1] https://mail.mozilla.org/pipermail/es-discuss/2012-December/027507.html


More information about the es-discuss mailing list