Rename the `async iterable` declaration to `async_iterable` to match the type name.

[tabatkins]

What is the issue with the Web IDL Standard?

Currently, you declare an interface to be an async iterable with an async iterable<ValType>; declaration, similar to the iterable<ValType>; declaration that marks it as a sync iterable. But when declaring a variable type for, say, an input argument, you write async_iterable<ValType> myArg, with an underscore. The latter was originally spelled the same way, as async iterable<ValType>, but was changed in #1490 for technical grammar reasons (it made the grammar no longer LL(1)).

Now, tho, that means authors have to keep two different spellings in their heads depending on where the term is used. The difference in the spellings isn't meaningful, either - it was changed solely to satisfy a technical constraint in the grammar, not for consistency, understandability, or any other "human" constraint. We have to do this sometimes, but this means we're now left with a human-facing inconsistency instead.

If we are indeed stuck with the underscore in the type name, we should use it for the interface declaration as well, to keep things consistent.

[domenic]

We cannot use the same name for the two different concepts, because then the grammar is ambiguous (not LL(1)): you don't know whether you're parsing a declaration or a type until after you see the next token.

Note that this is solved for sync iterables by using totally different names: iterable<> declarations and sequence<> types.

[annevk]

So maybe we should have async_iterable and async_sequence? Having them differ by just an underscore is too confusing.

[saschanaz]

iterable vs sequence sounds good to me, making it consistent with the non-async pair.

[saschanaz]

@tabatkins are you willing to do the change in #1500 or should I open a new PR?

[tabatkins]

We cannot use the same name for the two different concepts, because then the grammar is ambiguous (not LL(1)): you don't know whether you're parsing a declaration or a type until after you see the next token.

Ahhh, I didn't realize that was actually the grammar issue. That makes sense!

Then yeah, I think using async_sequence for the value type would make a lot of sense, to pull it farther away.

We should probably be consistent in underscore use between the two instances, I guess? I'd be fine with async_iterator for the interface declaration, but is the other way possible? Does async sequence<...> violate LL(1)? (I think either way is fine.)

@saschanaz I can do the change, if we know what we're agreeing to.

[saschanaz]

async sequence may be fine? And maybe even better as that'll require no downstream spec changes (as async iterable remains as is)

[tabatkins]

Since we only use spaces for the other multi-word types, like unsigned long long, I think async sequence<> would read better. Refreshing my intuition on LL(1) restrictions again, I think that would be fine, yeah - there's no terminal also matched as a prefix of another production.

[saschanaz]

Since we only use spaces for the other multi-word types, like unsigned long long,

(which reminds me #843)

[tabatkins]

#1500 is updated to async sequence<>, assuming that sounds good to the editors.

[tabatkins]

As I caught in #1500, nope, I misunderstood the LL(1) restrictions. async sequence still violates LL(1), because it shares a prefix with async iterable. The only way around that would be to form the two words into a single token, but that fixes a particular whitespace, so isn't really doable.

So no, I think async_sequence<> is the way to go. I'm actually more okay keeping async iterable and async_sequence differing in space vs underscore, but I can go change #1500 to use underscore in both places if desired.

[annevk]

I would make both use underscores. Long term we're going to revise those number types and we can make them consistent then.

[tabatkins]

This isn't about the number types, fwiw. async iterable<> is the declaration that makes an interface into an async iterable, like iterable. The number types are instead alongside async_sequence<>, which uses the underscore in contravention of the (current) precedent the number types set.

But I'm happy to have them both use underscores, it just means we'll need to modify a few specs that currently use async iterable.

[annevk]

I understand, but it seems likely we'll want to introduce more async declarations in the future, such as #1488. At which point I think we'd have to change it to an underscore so we might as well do that now.

[saschanaz]

Yup, and there are only a few specs with async_iterable.