Hopefully last word on Use Strict Directive syntax

Allen Wirfs-Brock Allen.Wirfs-Brock at microsoft.com
Mon Jun 8 15:56:47 PDT 2009

Waldemar's notes from the last TC39 F2F say:

"use strict" resolution:  A use strict directive must be the literal string "use strict".  It must occur before any statement other than other literal string-semicolon pairs.

Based upon this and my notes I have redrafted section 14.1 as follows:

14.1 Directive Prologues and the Use Strict Directive

A Directive Prologue is a sequence of zero or more  ExpressionStatement productions, each of which consists entirely of a StringLiteral, that occur as the initial SourceElement productions of a Program or FunctionBody.

A Use Strict Directive is an ExpressionStatement in a Directive Prologue whose StringLiteral is either the exact character sequences "use strict" or 'use strict'.


A Use Strict Directive may not be written containing EscapeSequence or LineContinuation.

The ExpressionStatement productions of a Directive Prologue are evaluated normally during evaluation of the containing SourceElements production. Implementations may define implementation specific meanings for ExpressionStatement productions which are not a Use Strict Directive and which occur in a Directive Prologue.  If an appropriate notification mechanism exists, an implementation should issue a warning if it encounters in a Directive Prologue an ExpressionStatement that is not a Use Strict Directive or which does not have a meaning defined by the implementation.

A Directive Prologue may contain more than one Use Strict Directive. However, an implementation may issue a warning if this occurs.
There are several other spec.  changes necessary to make this fit it, but the above is the heart of the matter.  Does anyone have any issues with it???

I couldn't think of any good reason for why we preferred double quote strings over single quote strings.  Other embellishments are a result of accomidating the possibility of multiple implementation defined directives.

I can imagine that the restriction of strings containing EscapeSequences or LineContinuations might complicate the lexer/parser factoring of some implementations but my recollection is that we wanted to require the precise lexical sequences defined above rather than any equivalent values.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es5-discuss/attachments/20090608/6b53ecb9/attachment-0001.html>

More information about the es5-discuss mailing list