Hi @frankwallis, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.

TTYL, MSBOT;

Thanks! i wounded what is the best way to make sure this does not happen again without adding "use strict"... Ideas?

So it looks like the compilation would have failed if this code was part of a class, as classes are automatically put into strict mode:

"Identifier expected. '{0}' is a reserved word in strict mode. Class definitions are automatically in strict mode.": {
        "category": "Error",
        "code": 1213
    },

I don't know the reason why non-classes are currently excluded from this sort of check, maybe it's a back-compatibility feature?

As per the ES6 spec, classes and modules are parsed in strict mode. This is not the case for other constructs. These are only parsed in strict mode iff the contains scope contains a "use strict" directive.

Ideally we would put "use strict" everywhere, except that it has perf impact as engines can not make norml optimizatios all the time.

I guess we need a parseStrict flag that makes the compiler always in strict mode.

@mhegazy

Thanks! i wounded what is the best way to make sure this does not happen again without adding "use strict"... Ideas?

Why not just add "use strict" to the top of all our files? There's no reason we'd want our code to be doing things that wouldn't work in strict mode.

deally we would put "use strict" everywhere, except that it has perf impact as engines can not make normal optimizatios all the time.

This seems fishy to me. "use strict" gives you a subset of javascript, with some bad stuff disallowed. I would be very surprised if we saw any perf hit at all from using 'use strict'.

I guess we need a parseStrict flag that makes the compiler always in strict mode.

This seems like vast overkill. If you want strict mode, then use "use strict". That's what it's there for. I don't think we need another compiler option for such an esoteric use case that is already handled fine with an existing language construct.