Rationale

A initialize-once, read-only thereafter binding form is useful and has precedent in existing implementations, in the form of const declarations.

Requirements

  • syntactic requirement: const declarations must have initializers for each declared identifier
    • we can’t afford (inter-procedural) static analysis to ensure the property will be written before it’s read
    • and an unsafe analysis would leave us in a middle-ground, where we still need dynamic checks for uninitialized reads
  • prefer “temporal dead zone”:
    • need a dynamic semantics for dealing with uninitialized properties
    • we don’t want to have to add an “uninitialized” attribute for object properties simply to support const
    • so we want to separate the notion of an uninitialized property from an uninitialized binding
  • still may want to allow for the possibility of implementations rejecting programs statically based on detected read-before-write

Semantics

  • const has block scope, like let
  • when environment frame is declarative, creates an initialize-only binding in the frame
  • when environment frame is an object, creates an initialize-only binding in the frame but not in the backing object
    • when the binding is initialized, checks the backing object
    • if there already is a property, raises an error
    • if there is no such property, creates a non-configurable, non-writeable property and sets it to the initialization value
  • thus in global code, there’s a reasonably clear and consistent semantics for const that doesn’t leak the notion of uninitialized properties into the global object
 
harmony/const.txt · Last modified: 2009/09/24 21:57 by brendan
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki