block params as number?

[stevenvachon]

{{#path 1 2 3 as |4|}} text {{4}} {{/path}}

Should we not throw an error if the first char in the variable name is not a letter?:

{{#path 1 2 3 as |a4|}} text {{a4}} {{/path}}

[kpdecker]

There has never been a requirement that we follow javascript id patterns, so {{4}} is just fine in the language. What is the argument for changing this?

[stevenvachon]

It conflicts with {{4}} which is already supported by handlebars as a number literal.

[kpdecker]

I don't believe this to be the case from my test compilation, it resolves
the value (or helper) "4". Can you put together a fiddle showing the
opposite if you are seeing different behavior?
On Wed, Mar 16, 2016 at 10:15 AM Steven Vachon [email protected]
wrote:

It conflicts with {{4}} which is already supported by handlebars as a
number literal.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1199 (comment)

[stevenvachon]

It conflicts semantically and doesn't work as might be expected; no actual error. Because of this, it should probably throw when being parsed.

console.log( require("handlebars").compile("{{#each list as |value 4|}} {{value}} {{4}} {{/each}}")({list:[0]}) )

…produces 0 0.

An example of something similar that does throw a parse error:

{{#each list as ||}} {{/each}}

[kpdecker]

This is operating as expected, {{4}} is resolving the second block parameter. Without the block parameter it would resolve to context['4'] so both behaviors are consistent. There is some level of oddity as numbers are treated as literals in any other position, but I'm not willing to break a use case that has been around for this long because someone chooses a bad variable name.