Discuss
  • Creating top-level scopes in ES6 and do blocks

Creating top-level scopes in ES6 and do blocks

# Axel Rauschmayer (12 years ago)

What is the best way to create top-level scopes in ES6?

This isn’t possible, any more, right (given that nested module won’t be in ES6)?

module {
    let foo = ...;
}

Then we are left with:

{
    'use strict';
    let foo = ...;
}

On the other hand, it would be nice to have do { ... } blocks (of which I don’t know the current status), which would eliminate the remaining use case for IIFEs. With do blocks, the above would become shorter:

do {
    let foo = ...;
}

It may make sense to terminate this expression statement with a semicolon.

Axel

# Marius Gundersen (12 years ago)

Instead of do-blocks you can use labelled blocks:

myBlock: {
  let foo = ...;
}```

This is nothing more than a label before a block. What is neat about this
is that break works inside the block, so:

```js

var myGlobal = 5;

myBlock: {
  let foo = Math.random();
  if(foo<0.5) break myBlock;
  myGlobal = 10;
}
console.log(myGlobal); //50% of the times it will be 5, 50% of the times it
will be 10.

This all works today (except for the let declaration), so not sure if anything is needed to replace this.

Marius Gundersen

# Jason Orendorff (12 years ago)

On Mon, Nov 4, 2013 at 5:36 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

What is the best way to create top-level scopes in ES6?

I guess I am probably missing something important, but I thought you could just write a block and use let in it:

{
    let foo = ...;
    ...
}

even in sloppy mode.

# Axel Rauschmayer (12 years ago)

My bad: I should have made it clear that I wanted top-level blocks in strict mode. Modules are implicitly in strict mode, normal code blocks aren’t. I was looking for a way to avoid 'use strict';

# Mark S. Miller (12 years ago)

On Mon, Nov 4, 2013 at 11:21 AM, Axel Rauschmayer <axel at rauschma.de> wrote:

My bad: I should have made it clear that I wanted top-level blocks in strict mode. Modules are implicitly in strict mode, normal code blocks aren’t. I was looking for a way to avoid 'use strict';

Hi Axel, Why were you looking for a way to avoid 'use strict'; ?

# Axel Rauschmayer (12 years ago)

On 05 Nov 2013, at 6:35 , Mark S. Miller <erights at google.com> wrote:

On Mon, Nov 4, 2013 at 11:21 AM, Axel Rauschmayer <axel at rauschma.de> wrote: My bad: I should have made it clear that I wanted top-level blocks in strict mode. Modules are implicitly in strict mode, normal code blocks aren’t. I was looking for a way to avoid 'use strict';

Hi Axel, Why were you looking for a way to avoid 'use strict'; ?

I don’t mind terribly, but I liked the idea of implicitly switching to strict mode via module { ... }, as it meant that there would be less visual clutter.

# Rick Waldron (12 years ago)

On Mon, Nov 4, 2013 at 2:41 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

On 05 Nov 2013, at 6:35 , Mark S. Miller <erights at google.com> wrote:

On Mon, Nov 4, 2013 at 11:21 AM, Axel Rauschmayer <axel at rauschma.de>wrote:

My bad: I should have made it clear that I wanted top-level blocks in strict mode. Modules are implicitly in strict mode, normal code blocks aren’t. I was looking for a way to avoid 'use strict';

Hi Axel, Why were you looking for a way to avoid 'use strict'; ?

I don’t mind terribly, but I liked the idea of implicitly switching to strict mode via module { ... }, as it meant that there would be less visual clutter.

Correct me if I'm wrong (just trying to undestand this): you're looking for something simple like

{ let ... }

That also has the implicit strictness of module body?

# Axel Rauschmayer (12 years ago)

I don’t mind terribly, but I liked the idea of implicitly switching to strict mode via module { ... }, as it meant that there would be less visual clutter.

Correct me if I'm wrong (just trying to undestand this): you're looking for something simple like

{ let ... }

That also has the implicit strictness of module body?

Yes, exactly! Well, maybe more like wondering what inline module bodies are best replaced with. They originally seemed like the ES6 version of the top-level IIFE, with the advantage of implicit strictness (compared to normal blocks + let).