CoffeeScript `use strict` #1547

geraldalewis · 2011-07-26T21:22:05Z

use strict

ECMAScript 5 introduces a strict mode that reduces bugs, increases security, and eliminates some difficult to use language features. The coding standards strict mode requires should be adopted by CoffeeScript.

Better Code

CoffeeScript emits lowest common denominator JavaScript. From a different angle: CoffeeScript emits JavaScript that is not implementation specific. Just as there are constraints on output imposed by IE6's nonconforming behavior (no function declarations), there too should be constraints on input imposed by better engineered environments.

User Expectations

CoffeeScript throws errors when it encounters syntax errors (e.g., one can't write -> return return). A user employing the use strict directive will expect to see syntax errors at compile time (pre-evaluation), just as they would in a JavaScript environment.

Best Practices

CoffeeScript emits JavaScript that adheres to best practices. ES5 strict codifies many best practices, and fixes some unsafe and error-prone operations. CoffeeScript already shares some constraints with strict (e.g., no with) and fixes others that strict targets (e.g., in CoffeeScript, vars are auto-declared for variable safety).

Early Errors

"Early errors" are syntax errors detected prior to evaluation (all others are runtime errors). Most strict mode errors are syntax errors (of type SyntaxError). CoffeeScript should only check for these types of errors. 16 Errors states: "An implementation shall not treat other kinds of errors as early errors even if the compiler can prove that a construct cannot execute without error under any circumstances" (emphasis mine).

Early Strict Syntax Errors

The following CoffeeScript snippets would be considered "early errors" under ES5 strict.

7.8.3 Numeric Literals

oct = 0121            # octals

B.1.2 String Literals

octEscSeq = "\121"    # octal escape sequences

11.1.5 Object Initialiser

x: 1, x: 1            # duplicate prop names in object literal

11.4.1 The delete Operator

x = 1; delete x       # delete var
delete undefined      # delete undefined 
(x)-> delete x        # delete function argument

13 Function Definition (13.1 Strict Mode Restrictions)

(x,x)->               # duplicate formal param

7.6.1.2 Future Reserved Words

implements = 1        # assigning to future reserved keyword
interface = 1
let = 1
package = 1
private = 1
protected = 1
public = 1
static = 1
yield = 1

eval and arguments restrictions

12.14 The try Statement (12.14.1 Strict Mode Restrictions)

try e catch eval      # catch identifier eval
try e catch arguments # catch identifier arguments

13 Function Definition (13.1 Strict Mode Restrictions)

(eval)->              # identifier "eval" in formal params
(arguments)->         # identifier "arguments" in formal params
class eval            # function declaration `function eval(){}`
class arguments       # function declaration `function arguments(){}`

11.13.1 Simple Assignment

eval = 1              # assigning to eval
arguments = 1         # assigning to arguments

11.3.1 Postfix Increment Operator

eval++                # incrementing eval
arguments++           # incrementing arguments

as well as Postfix Decrement and Prefix Increment and Decrement

What Users Would Give Up

Some coding conventions would need to be abandoned, namely:

Identical param names

used for parameters that are not germane to the function's body
useful in callbacks

e.g.,

(_,_,_,buffer) -> #read buffer

However, as @jashkenas stated "...is a serious antipattern. For the reader who comes across your function, intending to modify it ... not only are they unable to use the first three parameters -- they also have not the slightest clue what the parameters might be."

@satyr also offered a workaround: ({},{},{},buffer) -> #read buffer would still be legal

Identical prop names in object literals

could be useful for debugging

@satyr's example:

o =
  a: console.debug "before a"
  a: getA()
  b: console.debug "before b"
  b: getB()

I'd argue that it's likely this feature is more often the cause of bugs foo: 1, bar: 2, bar: 3 # user meant 'baz' and catching those errors would outweigh its other uses.

(and one could still write):

o =
  a: do -> console.debug "before a"; getA()
  b: do -> console.debug "before b"; getB()

Sources/More Information
Annotated ES5 Spec
ES5 Spec: Annex C "The Strict Mode of ECMAScript "
JavaScript Strict Mode Tests
ECMA-262-5 in detail. by Dmitry Soshnikov
ES5 Browser Compatibility Table by @kangax

The text was updated successfully, but these errors were encountered:

josh · 2011-07-26T23:30:24Z

(subscribe)

ayosec · 2011-07-26T23:53:32Z

+1

michaelficarra · 2011-07-27T00:03:16Z

@josh: there's now a link at the bottom of issues that allows you to {,un}subscribe without posting. It's actually been there for a few months now.

jashkenas · 2011-07-27T00:17:20Z

@michaelficarra: @josh works at GitHub ;)

In any case, I think this ticket makes a very strong argument for having CoffeeScript be "use strict" compliant to the extent statically possible.

The only real downsides here are the inability to use the FutureReservedWords as identifiers ... but it seems like folks don't tend to do that:

http://www.google.com/codesearch#search/&q=%5Cbvar%5Cs%2B(implements%7Cinterface%7Clet%7Cpackage%7Cprivate%7Cprotected%7Cpublic%7Cstatic%7Cyield)%5Cb&type=cs

michaelficarra · 2011-07-27T04:51:29Z

So let's clarify this proposal. Do we enforce strict mode restrictions everywhere or only in contexts that begin with a "use strict" directive? If everywhere, do we output a "use strict" directive at the top of our IIFE wrapper?

Side note: the delete undefined example from the OP exposes a bug in our current compilation, but if we're going to disallow deletion of "a direct reference to a variable, function argument, or function name", this problem will just go away.

michaelficarra · 2011-07-27T05:06:43Z

edit: never mind, @geraldalewis already got it

geraldalewis · 2011-07-27T10:26:49Z

Good point @michaelficarra

Since strict mode affects some subtle runtime behavior, and since that runtime behavior is not cross-browser/environment, strict mode should be opt-in. For instance, in non-strict, changing the value of a property of the arguments object will change the value of the corresponding argument binding, while in strict there's no dynamic binding between arguments and the individual arguments defined by the formal params.[2]

From @kangax's ES5 Browser Compatibility Table:
strict

((x)-> x = 2; arguments[0] is 1)(1) # true

non-strict

((x)-> x = 2; arguments[0] is 1)(1) # false

That'd probably break some users' code if they're not expecting it (not that there isn't arguments weirdness in different implementations[2]).

Related to the "use strict" directive prologue itself: it might be a good idea for the compiler to communicate that "use strict" shouldn't appear outside an IIFE when compiling with --bare in case the file is concatenated with other js files. Douglas Crockford warns "If a file with a "use strict"; preamble has sloppy code appended to it, the sloppy code will be processed as strict and will probably fail. There is an easy rule: Do not mix strict and sloppy in the same file, but we have already seen some famous websites get this wrong."[3] Would a warning work? (I can't find precedents for warnings outside of compiling with the --lint option; am I missing some?). There may be a use case for "use strict" outside an IIFE I'm not thinking of, however.

Would love to hear about the bug delete undefined exposed -- tried to find it myself last night to no avail.

[1] ES5 Annotated Spec 10.6 Section 1
[2] Angus Croll, The JavaScript arguments object… and beyond
[3] Douglas Crockford, Strict Mode is Coming to Town

jashkenas · 2011-07-27T12:26:44Z

I think if we do this, we enforce our static strict mode restrictions everywhere, but we do not put any "use strict" directives into your code for you.

geraldalewis · 2011-07-27T13:44:24Z

Agreed @jashkenas -- I just came back to clarify that the early strict syntax checks should be made regardless of whether or not the user has chosen strict mode.

geraldalewis · 2011-07-27T16:14:07Z

In the interest of deepening the discussion, it was proposed in #1002 (duplicate parameter names) that instead of throwing an error, CoffeeScript could rewrite the offending code. The following CoffeeScript snippets show:

1. code that would raise a SyntaxError under `use strict`
2. conversion of that code to a safe form (expressed in CoffeeScript)
3. the sanitized JavaScript output

For the record, I think SyntaxErrors are a better way to handle strict mode restrictions.

7.8.3 Numeric Literals

oct = 0121
oct = 81                  # convert to decimal
var oct = 81              # js output

B.1.2 String Literals

octEscSeq = "\121"
octEscSeq = "\x51"        # convert to hex escape sequence
var octEscSeq = "\x51"    # js output

11.1.5 Object Initialiser

x: console.log('x'), x: 1 
x: do -> console.log('x'); 2  # each assignment wrapped into single `IIFE`
{ x: (function() {            # js output; return second assignment's value
  console.log('x'); 
  return 2; })() 
};

11.4.1 The delete Operator

x = 1; delete x           
x = 1;                    # remove `delete x`
var x = 1;                # js output

13 Function Definition (13.1 Strict Mode Restrictions)

(x,x) ->                  
(x,x2) ->                 # rename 2nd param to be unique
function(x, x2) {}        # js output

7.6.1.2 Future Reserved Words

implements = 1            
_implements = 1           # `_` prefix added
var _implements = 1;      # js output

The eval/arguments issues can be resolved with a rename

try e catch eval          
try e catch _eval         # `_` prefix added
try { e; } catch (_eval) {}# js output

(arguments)->             
(_arguments)->            # `_` prefix added
function(_arguments) {}   # js output

class eval
class _eval               # `_` prefix added
function _eval(){}        # js output

arguments = 1
_arguments = 1            # `_` prefix added
var _arguments = 1        # js output

eval++
_eval++                   # `_` prefix added
_eval++                   # js output

Obfuscation and Intent

However, these code transformations would subvert the intention behind the strict restrictions. In the case of duplicate param names and duplicate object props, this strategy would further obfuscate hard to detect bugs. A user attempting to delete a var, arg or function declaration should be warned that their action isn't having the intended effect. eval and arguments as identifiers is a bad idea.

jashkenas · 2011-07-27T16:22:04Z

Agreed -- much much better to SyntaxError than to change your semantics on the sly.

michaelficarra · 2011-07-27T16:38:36Z

For the record, I think SyntaxErrors are a better way to handle strict mode restrictions.

I think the conversion is better for some, but not all, strict mode restrictions.

7.8.3 Numeric Literals

oct = 0121
oct = 81                  # convert to decimal
var oct = 81              # js output

+1

B.1.2 String Literals

octEscSeq = "\121"
octEscSeq = "\x51"        # convert to hex escape sequence
var octEscSeq = "\x51"    # js output

+1

11.1.5 Object Initialiser

x: console.log('x'), x: 1
x: do -> console.log('x'); 2  # each assignment wrapped into single `IIFE`
{ x: (function() {            # js output; return second assignment's value
  console.log('x');
  return 2; })()
};

I'd prefer this conversion:

o = {};
o.x = console.log('x');
o.x = 1;

11.4.1 The delete Operator

x = 1; delete x
x = 1;                    # remove `delete x`
var x = 1;                # js output

-1 no way to preserve semantics: SyntaxError

13 Function Definition (13.1 Strict Mode Restrictions)
(x,x) ->
(x,x2) ->                 # rename 2nd param to be unique
function(x, x2) {}        # js output

(x,x) -> should be function(_unused, x){}

7.6.1.2 Future Reserved Words

implements = 1
_implements = 1           # `_` prefix added
var _implements = 1;      # js output

var implement\u0073 = 1

The eval/arguments issues can be resolved with a rename
try e catch eval
try e catch _eval         # `_` prefix added
try { e; } catch (_eval) {}# js output

-1 no way to preserve semantics: SyntaxError

(arguments)->
(_arguments)->            # `_` prefix added
function(_arguments) {}   # js output

-1 no way to preserve semantics: SyntaxError

class eval
class _eval               # `_` prefix added
function _eval(){}        # js output

-1 no way to preserve semantics: SyntaxError

arguments = 1
_arguments = 1            # `_` prefix added
var _arguments = 1        # js output

-1 no way to preserve semantics: SyntaxError

eval++
_eval++                   # `_` prefix added
_eval++                   # js output

-1 no way to preserve semantics: SyntaxError

Obfuscation and Intent

However, these code transformations would subvert the intention behind the strict restrictions. In the case of duplicate param names and duplicate object props, this strategy would further obfuscate hard to detect bugs.

A user attempting to delete a var, arg or function declaration should be warned that their action isn't having the intended effect.

No, it should definitely be a SyntaxError, no question.

eval and arguments as identifiers is a bad idea.

agreed.

geraldalewis · 2011-09-07T01:27:26Z

JSLint throws an error if you don't include the "use strict" pragma* . Developers naïvely include it to prevent the error, but do not properly test their code with a browser that supports strict mode. Or code with the global "use strict" directive is concat'ed with non-strict code, breaking it. Bugs are then filed against browsers who correctly throw errors when "use strict" breaks some functionality on a big website.

This may lead to what @BrendanEich calls "strict quirks mode".

Raising SyntaxErrors on "early errors" will not only help devs who incorrectly enable strict mode, but will add a layer of defense for CoffeeScript programs that are concat'ed into strict mode. "use strict" is a good and valuable thing for JavaScript, and therefore it's good for CoffeeScript. We can do our part and require better, safer, and more reliable code from CoffeeScript developers.

* Unless the "sloppy" flag is set to true, something I doubt a dev who uses JSLint would like to do. By calling it "sloppy", Crockford has, frustratingly, created a moral imperative for employing "use strict" (like Knuth did [tongue-in-cheek] with Literate Programming -- "nobody wants to admit to an illiterate program.")

@michaelficarra

RegExp updated (thanks @michaelficarra) and hex escapes for colors in Cakefile tests updated (thanks @satyr) error message conforms to existing Lexer SyntaxErrors

…bj literals prohibited

@davidchambers

…ibited updated error message (thanks @davidchambers) code style fixes

…iers prohibited

… 0o777 Allows octals in the form '0o777' and '0O777' Case insensitive Disallows decimals prefixed with '0'

… output

michaelficarra · 2012-04-03T18:55:25Z

I think this can be closed.

satyr · 2012-04-11T05:40:20Z

$ coffee -e '"use strict"; p: 1, "p": 2'

.:6
    "p": 2
    ^^^
SyntaxError: Duplicate data property in object literal not allowed in strict mode

satyr · 2012-04-11T05:50:09Z

$ node -e '"use strict"; "\0"'

$ coffee -e '"\0"'
SyntaxError: octal escape sequences "\0" are not allowed on line 1

devongovett · 2012-04-20T18:53:51Z

I am also wondering about the "\0" octal escape sequences being disallowed as well. If @satyr is correct these are allowed in JS even in strict mode. I have an SQL escape function that needs to replace "\0" with "\0" and now it won't compile. Any reason why, or is this a bug?

BrendanEich · 2012-04-20T20:50:33Z

SpiderMonkey shell:

js> "use strict"; "\0"
"\x00"
js> "use strict"; "\00"
typein:2: SyntaxError: octal literals and octal escape sequences are deprecated:
typein:2: "use strict"; "\00"
typein:2: ..............^
js> "use strict"; "\01" 
typein:3: SyntaxError: octal literals and octal escape sequences are deprecated:
typein:3: "use strict"; "\01"
typein:3: ..............^

The special case is for "\0" only, not anything else truly octal or "noctal" (not quite octal, e.g. \08, \09, etc.).

@devongovett: it's impossible to say what is going wrong without seeing that function, but it's not anything to do with strict mode as spec'ed or implemented in Firefox.

/be

devongovett · 2012-04-20T21:09:39Z

@BrendanEich Well here is the function:

escapeSQL = (val) ->
    val = val.replace /[\0\n\r\b\t\\\'\"\x1a]/g, (s) ->
        switch s
            when "\0" then "\\0"
            when "\n" then "\\n"
            when "\r" then "\\r"
            when "\b" then "\\b"
            when "\t" then "\\t"
            when "\x1a" then "\\Z"
            else "\\" + s

    return "'" + val + "'"

The error is thrown by the CoffeeScript compiler, not the JS side of things. CoffeeScript apparently isn't special casing "\0" like SpiderMonkey, V8 and probably others do. Luckily, this is workaroundable for the time being by using "\u0000" instead of "\0", but it still should be fixed.

BrendanEich · 2012-04-20T21:38:36Z

@devongovett new issue on file?

/be

Relevant sections of the spec: * http://es5.github.com/#C * http://es5.github.com/#B.1.2 * http://es5.github.com/#x7.8.4

michaelficarra · 2012-04-20T22:35:21Z

@devongovett: This should be fixed by 46ff770. Go ahead and try that out.

eugenioclrc · 2013-09-15T23:22:57Z

+1

This fixes a SyntaxError when using CoffeeScript 1.3.x. More info: jashkenas/coffeescript#1547

Almad · 2014-12-03T19:46:50Z

Related to #566 (that is open)...

My question more is: would it be possible to at least add it as an option? I'd be glad to have it feature-flagged, but we'd want to give it a try (on server).

Or is it wontfix for another reason?

hankphung · 2016-02-22T07:41:34Z

+1 : Cannot delete any variable.

-module.coffee:101:5: error: delete operand may not be argument or var
    delete   parser
    ^^^^^^^^^^^^^^^
    L100:     delete   parser

michaelficarra mentioned this issue Jan 3, 2012

Default values for destructuring parameters #1558

Closed

geraldalewis mentioned this issue Jan 9, 2012

Use Strict #2021

Merged

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' tests

66eb186

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' octal literals prohibited

cad108e

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' duplicate property definitions in o…

a2ef66f

…bj literals prohibited

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' duplicate formal parameter are proh…

7521068

…ibited updated error message (thanks @davidchambers) code style fixes

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' delete operands restricted

f43ec97

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' future reserved keywords as identif…

0b7cfba

…iers prohibited

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' eval and arguments use restricted

8b179fb

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' Python-style octal literal notation…

4372138

… 0o777 Allows octals in the form '0o777' and '0O777' Case insensitive Disallows decimals prefixed with '0'

geraldalewis added a commit to geraldalewis/coffee-script that referenced this issue Jan 16, 2012

Issue jashkenas#1547 'use strict' style tweaks, cleanup, and compiled…

bf8e0aa

… output

michaelficarra closed this as completed Apr 3, 2012

jimeh mentioned this issue Apr 14, 2012

Fix keep-alive-fix hubotio/hubot#271

Closed

kimptoc mentioned this issue May 6, 2013

Does this work with CoffeeScript? zvictor/ArgueJS#4

Closed

tomdionysus mentioned this issue Aug 4, 2013

TodoMVC Mozart example tastejs/todomvc#621

Merged

ToriTomyuTomyu pushed a commit to ToriTomyuTomyu/nothing-yet that referenced this issue Nov 6, 2013

Replace string literals in shell adapter with hex escape sequence

2f11797

This fixes a SyntaxError when using CoffeeScript 1.3.x. More info: jashkenas/coffeescript#1547

iandoe mentioned this issue Apr 28, 2014

Schema.static is replaced by Schema["static"] using coffeescript (es6 ?) Automattic/mongoose#2047

Closed

vendethiel mentioned this issue Jul 21, 2014

Can't use undefined as a parameter #3547

Closed

vendethiel added change fixed wontfix and removed fixed labels Nov 3, 2014

larssb mentioned this issue Feb 17, 2015

To which extent has the ECMASCript 5 strict mode directive been implemented..... #3860

Closed

This was referenced May 21, 2015

Expansion in parameter list makes parameters able to override higher-scope variables #3575

Closed

Stop enforcing parameter name uniqueness #3986

Closed

niieani mentioned this issue Dec 11, 2015

JavaScript driver provided in npm sometimes fails when executing in strict mode rethinkdb/rethinkdb#5198

Closed

lydell mentioned this issue Feb 9, 2016

Refactor Literal into several subtypes #4198

Merged

ivanreese mentioned this issue Apr 29, 2016

Use Strict cdig/take-and-make#6

Closed

jimeh mentioned this issue Jul 11, 2014

Fix SyntaxError in Shell adapter under CoffeeScript 1.3.x hubotio/hubot#272

Merged

anissen mentioned this issue Apr 10, 2012

Hash entries not deleted sargant/nodejs-stuff#4

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CoffeeScript `use strict` #1547

CoffeeScript `use strict` #1547

geraldalewis commented Jul 26, 2011

josh commented Jul 26, 2011

ayosec commented Jul 26, 2011

michaelficarra commented Jul 27, 2011

jashkenas commented Jul 27, 2011

michaelficarra commented Jul 27, 2011

michaelficarra commented Jul 27, 2011

geraldalewis commented Jul 27, 2011

jashkenas commented Jul 27, 2011

geraldalewis commented Jul 27, 2011

geraldalewis commented Jul 27, 2011

jashkenas commented Jul 27, 2011

michaelficarra commented Jul 27, 2011

Obfuscation and Intent

geraldalewis commented Sep 7, 2011

michaelficarra commented Apr 3, 2012

satyr commented Apr 11, 2012

satyr commented Apr 11, 2012

devongovett commented Apr 20, 2012

BrendanEich commented Apr 20, 2012

devongovett commented Apr 20, 2012

BrendanEich commented Apr 20, 2012

michaelficarra commented Apr 20, 2012

eugenioclrc commented Sep 15, 2013

Almad commented Dec 3, 2014

hankphung commented Feb 22, 2016

CoffeeScript use strict #1547

CoffeeScript use strict #1547

Comments

geraldalewis commented Jul 26, 2011

use strict

Better Code

User Expectations

Best Practices

Early Errors

Early Strict Syntax Errors

What Users Would Give Up

josh commented Jul 26, 2011

ayosec commented Jul 26, 2011

michaelficarra commented Jul 27, 2011

jashkenas commented Jul 27, 2011

michaelficarra commented Jul 27, 2011

michaelficarra commented Jul 27, 2011

geraldalewis commented Jul 27, 2011

jashkenas commented Jul 27, 2011

geraldalewis commented Jul 27, 2011

geraldalewis commented Jul 27, 2011

Obfuscation and Intent

jashkenas commented Jul 27, 2011

michaelficarra commented Jul 27, 2011

Obfuscation and Intent

geraldalewis commented Sep 7, 2011

michaelficarra commented Apr 3, 2012

satyr commented Apr 11, 2012

satyr commented Apr 11, 2012

devongovett commented Apr 20, 2012

BrendanEich commented Apr 20, 2012

devongovett commented Apr 20, 2012

BrendanEich commented Apr 20, 2012

michaelficarra commented Apr 20, 2012

eugenioclrc commented Sep 15, 2013

Almad commented Dec 3, 2014

hankphung commented Feb 22, 2016

CoffeeScript `use strict` #1547

CoffeeScript `use strict` #1547