The rationale for strict mode
david.hopwood at industrial-designers.co.uk
Thu Nov 13 14:53:08 PST 2008
Section 4 of the Kona draft says:
# [...] A scripting language is intended for use by both professional
# and nonprofessional programmers. To accommodate non-professional
# programmers, some aspects of the language are defined to be tolerant
# of programmer mistakes. However, such tolerance can easily result in
# programs containing undiscovered errors that professional programmers
# would wish to discover and correct. To facilitate such error detection
# script can be explicitly declared to use a "strict" variant of the
# full ECMAScript language that provides enhanced error detection as well.
However, being "tolerant of programmer mistakes" is a very different
thing than *failing silently* on errors that are commonly caused by
programmer mistakes, which is what ES3, and ES3.1 in non-strict
mode, actually do.
One could make a convincing argument that the behaviour that is
most tolerant of mistakes is to report error conditions resulting
from the mistake as soon as possible, in as many cases as possible.
to teach the ES3.1-strict subset, *especially* to beginning
The basic technical rationale for strict mode is that there were
some language design flaws that we couldn't compatibly fix without
using an opt-in. Strict mode is that opt-in. It has nothing much
to do with whether programmers are professional, or amateur, or
I understand why, for political reasons, the standard document can't
were just bad language design. However, if it can't say that then it
should at least avoid trying to rationalize historical mistakes. The
text quoted above does not provide a helpful or accurate rationale
for either mode.
- delete the above two sentences.
- add the following, perhaps before the "A scripting language ..."
ECMAScript code can be run in two modes, "strict" and "non-strict"
(these may be mixed in the same program). Strict mode reports many
error conditions, such as accessing a non-existent property of an
object, by throwing an exception. In non-strict mode these
conditions silently cause the operation to be ignored or the
'undefined' value to be used as the result. Previous versions of
ECMAScript supported only the non-strict semantics. Although the
strict semantics are generally preferable, the behavior could not
be compatibly changed without adding strict mode as an "opt-in"
More information about the Es-discuss