{#range ...} block

[Rich-Harris]

Never thought I'd say this but I think we need range blocks — we've had so many questions along the lines of 'how do I iterate n times?'.

The usual answer is one of these...

{#each Array(n) as _, i}
  <p>{i}</p>
{/each}

{#each { length: n } as _, i}
  <p>{i}</p>
{/each}

...but neither is particularly satisfying.

Anyway, we're a compiler, so we can add this for free, if we want to. The only real question is syntax. We could emulate Ruby's range operator:

<!-- 1,2,3,4,5 -->
{#range 1..5 as n}
  {n}
{/range}

<!-- 1,2,3,4 -->
{#range 1...5 as n}
  {n}
{/range}

{#range 5 as n} could be shorthand for {#range 0...5 as n}, perhaps.

Complications: Ruby's operator also handles decrementing ranges (5...1) and strings ('a'...'z' and 'z'...'a'), so if we were to steal that syntax then presumably we should also support those.

Any thoughts?

[paulocoghi]

If this feature will not impact the generated code on projects that doesn't use it, there is no impediment, IMHO.

[mrkishi]

I'm honestly all in for a range block. I dislike Ruby's syntax, though. :/

Nim, swift and others use < to denote open intervals:

{#range 1..5 as n}  // closed: 1,2,3,4,5
{#range 1..<5 as n} //   open: 1,2,3,4

It's not exactly pretty, but it's much more intuitive than Ruby's, imo. Maybe there's something else entirely?

On your last point, I think even with variables (ie. runtime juggling), decrementing ranges would be fairly minimal to support. I don't know about characters...

[pngwn]

I'm actually the opposite, I really like the ruby range syntax. I think it is simple and clear.

[joeprabawa]

i'd like the idea using this syntax {#range 5 as n}. Maybe we can refrence vue v-for with range ?

https://vuejs.org/v2/guide/list.html#v-for-with-a-Range

[onkel-dirtus]

I like the idea of adding support for range syntax to the each block rather than adding a new range block.

[iambudi]

Agree with @onkel-dirtus to use #each block.

{#each 5 as n}
  {n}
{/each}

{#each 1..5 as n}
  {n}
{/each}

[Conduitry]

{#each 5 as n} is bad because we won't be able to statically determine whether this is a range or an array iteration. (Unless it only works with literal numbers, which is also bad.) Whatever the syntax is, it needs to be clear at compile time whether we are doing a range thing or an array thing.

[tivac]

@Conduitry why can't the compiler statically determine that {#each 5 as n} is a range? 5 isn't a valid JS identifier, so that seems like a good place to start for figuring out if the user specified a range or an array to me.

I don't much care if range support gets added, but always curious about the static analysis bits.

[pngwn]

It can't be statically analysed if a variable is used instead of a literal number (n instead of 5), which means the range would only work for literal numbers and not variables, in this case.

The reason for this is that value could be provided at runtime, so the compiler will never get the chance to optimise it. I guess it would be possible to make each work with numbers or array-likes at runtime but then everyone would pay for the feature.

[tivac]

@pngwn that's what is being asked for by at least some of the proposals though, a literal number. The compiler could easily identify that value and write out range code instead of array iteration code.

[pngwn]

I think that is why conduitry said:

Unless it only works with literal numbers, which is also bad.

I am in agreement here, limiting it to only literal numbers reduces the usefulness of range syntax. The point, to me, is to provide a more elegant syntax for iterating a set number of times without requiring an array-like. Forcing people who are using values only known at runtime to go back to { length: n } defeats the point somewhat.

[sahajre]

I do not have much experience in open source community (yet), but I found this community very diverse and open, hence daring to share my opinion.

I am sorry, but I am bit skeptical about this. I believe learning new language with minimal syntax is much easier and possibly less confusing. So, feeling uncomfortable having a separate block for special case of iterating.

Also, afraid that there is a possibility of #each and #range blocks getting used interchangeably. i.e. #range on arrays and #each on numbers, leading to more queries and clarifications.

I don't think I am capable enough to suggest, but it would be good if there can be syntax addition for range in #each block itself.

[buhrmi]

I'm new too, but I'm with @sahajre on this. Since it's a compiler, how about adding ranges as a syntax, eg. {#each [0..4] as n} which would be compiled into a vanilla for (n = 0; n <= 4; n += 1) {... loop, similar to how CoffeeScript does it.