Illegal const declaration in unprotected statement context.

[churchofthought]

I'm writing an asset plugin for node and I'm having a problem doing a const inside a switch:

switch (pathParts[0] = pathParts[0].trim()){
    case "assets":
    res.setHeader("Cache-Control", "max-age=31556900");
    // if cached, just return it
    if (req.headers["if-none-match"]){
        res.writeHead(304);
        res.end();
        return;
    }
    const hash = pathParts[1].trim();

The error is "Illegal const declaration in unprotected statement context."

I googled it but can't find any real explanation. What is an unprotected statement context and why is this const illegal?

[indutny]

If pathParts[0] will be not assets - hash won't be defined and it should be defined unconditionally. Anyway, if you think that v8 does not follow ECMA specification - feel free to open an issue on their bug tracker. I can't really help you much with it.

[churchofthought]

Sorry didn't realize that this was a v8 issue rather than a node issue. I understand that you can't help. Thanks.

[rlidwka]

If you're going to report it to v8, you can also mention this test case:

if (Math.random()>0.5) {
    const x=1
} else {
    const x=2
}

• FireFox throws "const redeclaration"
• node.js can return both 1 and 2
• Chromium seem to always return 2

[churchofthought]

I believe part of the inconsistent behavior is due to using const without "use strict" Then --harmony needs to be enabled on v8 to use const.

I will look into the matter and post a v8 bug if necessary. Thanks Alex

[rlidwka]

"use strict" has nothing to do with it, it is useless statement, and it doesn't affect harmony features at all.

[churchofthought]

@rlidwka --harmony allows const in strict mode I haven't taken a look at the code but I suspect there might be more than just a simple conditional warranting the change in behavior.

strict without harmony yields "SyntaxError: Use of const in strict mode."

[rlidwka]

--harmony allows const in strict mode

$ ~/node/node  -e 'const x=1;console.log(x)'
1
$ ~/node/node --harmony -e 'const x=1;console.log(x)'
1

It has nothing to do with harmony. Const is supported in v8. Period.

strict without harmony yields "SyntaxError: Use of const in strict mode."

Don't use strict mode, it's obviously harmful and break things.

[churchofthought]

How is it harmful? I was under the impression that strict was closer to the official javascript spec and v8 is quite lenient with malformed js.

[rlidwka]

How is it harmful?

You can't turn it off if you need it, which means people are forced to do silly things: https://github.com/joyent/node/blob/5e140b33e58bd0ac6779fb0cb635dd51e1a27289/lib/fs.js#L192

I was under the impression that strict was closer to the official javascript spec

I seriously hope you're kidding when you call a javascript that works everywhere since Netscape times "malformed js".

Strict mode is just a part of javascript, and it's perfectly fine (I'd even say encouraged) to write javascript without it. People need strict mode in some corner cases, like running not very trusted code in eval and ensuring it won't do much. But other than that, it don't make sense. Anyway, learn what your tools do before you use them, blindly putting some boilerplate in your js code is almost always a mistake.

[churchofthought]

rildwka, I'm versed in quite a lot of languages. It's a surprise for me to hear that strict mode is not preferred, because in pretty much every other language, it's preferred to have warnings be errors when developing, it helps prevent stupid mistakes. Though I appreciate your explanation, I've got to say, you've got quite a pudgy attitude. Of course I'm aware that JS has been around for a long time, I used to write firefox extensions with JS and XPCOM when Mozilla was the big player, and Firefox didn't even exist. Anyhow, I'm not looking for backwards compatibility, and I could care less what proper JS used to be. This code is server-side code and I'm looking for performance, so I've dialed up as many things as I can, and that includes const and strict which I thought could help the hotspot compiler with some optimizations. I'm busy developing my app so I don't have the utmost time to research these things in depth, there aren't all that many resources except for the v8 source code itself. From what I've read about const, it can actually be a performance penalty because the JIT engine has to enforce the const dynamically but harmony is supposed to change that. Things are changing and it's hard to keep abreast with the ES5 developments. Consider being more understanding. I'll have to read up more on strict mode to decide if I want to keep using it.

[rlidwka]

because in pretty much every other language, it's preferred to have warnings be errors when developing

In other languages like perl you have control over strict mode. You can turn it on, you can tune it and turn off features you don't like.

In javascript it's imperative. If someone is using strict mode, and you're editing the same file, you're forced to use it as well and can't do anything about it. That's the difference.

I've got to say, you've got quite a pudgy attitude.

Err... I'll probably need to say "sorry" about that, 'cause I really didn't slept much, and might accidentally say something that I didn't really mean, although I can't be sure of that. I wonder what I'll think when I re-read all this tomorrow...

This code is server-side code and I'm looking for performance, so I've dialed up as many things as I can, and that includes const and strict which I thought could help the hotspot compiler with some optimizations.

No it doesn't, has been checked. If you use strict mode, no additional optimizations are applied, because v8 is already doing all optimizations it can. For example, it just assumes that code doesn't use arguments.callee and bail otherwise, so it will work for both modes as well. Maybe firefox or something can make use of it, but I'm not very interested in that.

In general, strict mode only makes anything slower, because parsers are forced to support both strict and compatible modes and switch between them. But there is nothing we can do about it.

From what I've read about const, it can actually be a performance penalty because the JIT engine has to enforce the const dynamically but harmony is supposed to change that.

No. It is a performance penalty because const is not widely used, v8 is not fully support it yet, so v8 is currently just disabling all optimizations for it because it's better to spend human resources elsewhere.

I really need to start adding proof links to these walls of text, so here is one: https://code.google.com/p/chromium/issues/detail?id=80149

I'll have to read up more on strict mode to decide if I want to keep using it.

Suggesting this writeup, since it's the only one I found describing both its advantages and disadvantages, although I don't quite agree with it: http://webreflection.blogspot.ru/2011/06/es5-and-use-strict.html

[churchofthought]

It's all good rlidwka, you're being very helpful and I appreciate the discussion around this topic.

It appears that "use strict" can be placed inside a function scope, and it will only apply to that function -- I see this pattern in quite a few npm packages. The article you linked doesn't really mention how v8 handled strict internally and how strict affects performance. Given how strict can be applied to one scope, and not another, it makes sense that this switching, possibly of context/behavior, could be quite a performance drain. On the other hand, not having to worry about eval, and other possibly optimization-havoky techniques, could help the compiler out, so I'm really quite split here, and unsure. Not to say I doubt you - but I need to solidify the actual ramifications of "use strict" before I set my practices in stone. I really need to see some solid evidence based on the v8 source code, to feel fully confident about the issue at hand. I suppose I will do some research and source code digging this week/weekend if nothing pops up until then.

Thanks for the link, I will change my consts to vars. It's counter-intuitive that more specific declarations hurt performance but I guess that's what we get with a brutally tuned JIT engineered for a spec absent of specifics.

Thanks rlidwka