Uninitialized immutable bindings

# Jason Orendorff (15 years ago)

In 10.2.1.1.4, step 3 checks to see if the binding is an uninitialized immutable binding. But I don't think this can happen. I only see two places where immutable bindings are created: 10.5, to bind arguments when entering a strict function; and clause 13, when evaluating a FunctionExpression with a name. In both cases the immutable bindings are initialized right away. So it would seem step 3 can be removed.

# Mike Samuel (15 years ago)

2010/11/8 Jason Orendorff <jason.orendorff at gmail.com>:

In 10.2.1.1.4, step 3 checks to see if the binding is an uninitialized immutable binding. But I don't think this can happen. I only see two places where immutable bindings are created: 10.5, to bind arguments when entering a strict function; and clause 13, when evaluating a FunctionExpression with a name. In both cases the immutable bindings are initialized right away.  So it would seem step 3 can be removed.

Was the same mechanism supposed to be used for const locals?

# Mark S. Miller (15 years ago)

On Mon, Nov 8, 2010 at 7:44 AM, Mike Samuel <mikesamuel at gmail.com> wrote:

2010/11/8 Jason Orendorff <jason.orendorff at gmail.com>:

In 10.2.1.1.4, step 3 checks to see if the binding is an uninitialized immutable binding. But I don't think this can happen. I only see two places where immutable bindings are created: 10.5, to bind arguments when entering a strict function; and clause 13, when evaluating a FunctionExpression with a name. In both cases the immutable bindings are initialized right away. So it would seem step 3 can be removed.

Was the same mechanism supposed to be used for const locals?

Yes. But more changes are needed to support blocked scoped const in general. See harmony:block_scoped_bindings

for such draft revisions to ES5.