Discuss
  • "use strict 2"

"use strict 2"

# BelleveInvis (11 years ago)

I think that we can provide a "more strict" mode to deal with some long-lasting defects. In "more strict" mode, Implicit type conversion is disabled.Functions declarations are disabled. All function(){} are considered function literal expression.Statement labels are disabled or strictly restricted.A break statement or a "fallthrough" declaration is required to be added into the branches inside a switch statement.eval is disabled.

# David Bruant (11 years ago)

2013/7/24 BelleveInvis <infinte.cdda at hotmail.com>

I think that we can provide a "more strict" mode to deal with some long-lasting defects. In "more strict" mode,

Why? Who does this benefit? You provide 5 rules. What ties them together? Why not other rules? What would be the benefit of this new mode over additional external tooling (like TypeScript or JSLint/JSHint/ESLint, etc.)?

Be aware that TC39 seems to currently agree on the "1JS" idea which is pretty much not adding any new modes anymore. So you'll need to make a very strong case to change their mind :-)

# Claude Pache (11 years ago)

I consider your first three complaints as features instead of defects, and the last one as an expert feature. The "use strict" directive corrected only objectively problematic misfeatures.

—Claude

Le 24 juil. 2013 à 11:35, BelleveInvis <infinte.cdda at hotmail.com> a écrit :

# Brendan Eich (11 years ago)

BelleveInvis wrote:

I think that we can provide a "more strict" mode to deal with some long-lasting defects. In "more strict" mode,

  • Implicit type conversion is disabled.
  • Functions declarations are disabled. All function(){} are considered function literal expression.

This in particular is a private fetish -- whatever floats your boat, but nothing to put in the standard.

Function hoisting as a simplified letrec and to enable top-down program source decomposition is a feature.

# Alex Russell (11 years ago)

This doesn't even sound as useful as "restrict mode": restrictmode.org

I can sympathize with wanting more control over what to disable in the language; removing hazards is good...but it's unclear why the rules you suggest are the best ones to add under such a flag. It might be best to use something like a Traceur pass to implement the idea and get experience with how it works in practice.