Syntax

[chicoxyzzy]

Possible solutions

Arrow function syntax

// Irregular
() =*> ...

// not the same order as in regular generator functions
() =>* ...

// also wrong order
() *=> ...

// ASI hazard
*() => ...

Introduce new generator keyword for both function and arrow function

generator function() {}
const foo = async generator function() {};

class Foo {
  x = 1
  // No more ASI hazard!
  generator foo() {}
}

---

Previous discussions https://github.com/tc39/proposals/issues/216

[jridgewell]

@littledan and I had some hallway-track conversations about this. My thoughts were to add a gen keyword (much like the async keyword), and treat the * sigil as the ugly wart it is:

gen function foo() {} // same as function* foo() {}
foo = gen () => {};

class Foo {
  x = 1
  // No more ASI hazard!
  gen foo() {}
}

When creating an async generator, the order would be async gen.

[chicoxyzzy]

There is an ASI hazard here

foo = gen ()
  => {};

[jridgewell]

That's a syntax error currently, right? I don't understand how it would cause a new ASI hazard.

[MaxGraey]

I can imagine only two variants:
1.

foo = (*)(arg) => {};

foo = (*(arg)) => {};

second could be simplified for one / zero arguments as:

foo1 = (*arg) => {};
foo0 = (*) => {};

[ljharb]

Adding a new gen is interesting, but there's no value imo in abbreviating - why not generator? (it's not func or async fn etc)

[MaxGraey]

More radical solution is using different brackets like [] instead ():

foo1 = [] => {}
foo2 = [[first, second]] => {}  // with array destruction
foo3 = [a, b] => {}

[chicoxyzzy]

TBH, any of *=>, =>* or =*> look totally fine and clear to me.

[bathos]

*=> seems least surprising to me, with =*> seeming least obvious (it helps to still have ‘the arrow’ for recognition).

[jridgewell]

Adding a new gen is interesting, but there's no value imo in abbreviating - why not generator?

Either is fine with me.

*=> seems least surprising to me, with =*> seeming least obvious (it helps to still have ‘the arrow’ for recognition).

Least surprising, but still super ugly. I (as a relatively experienced JS dev) still struggle with the order for function * foo() {} ("is it before function, in between, or after the identifier?"). I imagine new devs are just as confused ("what does the star mean?").

A keyword would be less esoteric, and much easier to Google for. So extending generator support to arrow functions gives us a chance to tackle both with one proposal. 😃

[rumkin]

I vote for keyword gen and *=>.

[rumkin]

@ljharb

Adding a new gen is interesting, but there's no value imo in abbreviating - why not generator? (it's not func or async fn etc)

There is the answer in your question: as async is a shortening of asynchronous, thus gen could stand for generator.

[janwirth]

I vote for

const myGen = async gen () => yield await sth()
// or
async gen function myGen () { yield await sth() }

It I think it is more writeable readable than *:

• readable because you will not need to keep arbitrary special characters in his mental memory.
• writeable becauses async is the adjective and gen is the noun in our expression if read as a sentence. Like this we are closer to english grammar.

Thoughts on oother programming languages

• Haskell - it is very hard to read for beginners as sigils are used to create a DSL for working algebraic data types. It is hard to google for the meaning of sigils. Elm has very limited use of sigils and is much more readable documentation is more retrievable IMO
• PHP makes extensive use of $. I find it just makes variable less legible as you need too visually segment the sigil and the variable name.

[ljharb]

@rumkin async is a well-known abbreviation for asynchronous, and is effectively a word on its own; gen is not.

[janwirth]

@ljharb - I agree. I also think it is easier to type and thus less useful to abbreviate.

Researches found that "Shorter identifier names take longer to comprehend"
https://link.springer.com/article/10.1007%2Fs10664-018-9621-x

[bathos]

If a keyword is introduced for the arrow case, does it necessarily mean also introducing it for the ‘longhand’ case?