Looking for some clarity on Promise<void>

[bathos]

In the description of void, it’s stated that

The only place that the void type may appear in IDL is as the return type of an operation.

However when describing the ES binding rules for Promise types, in the algorithm perform some steps once a promise is settled, it says:

If T [of Promise<T>] is void, then [...]

Is Promise<void> is permitted, but only as a return type? If so, should the first text be amended to clarify that, or am I misunderstanding what ‘return type’ is inclusive of?

[TimothyGu]

The first piece of text seems to predate the introduction of Promise<T>. Technically void may indeed only appear in return types (as defined by the ReturnType production), but the T in Promise<T> also matches ReturnType per the grammar.

So yes, Promise<void> is permitted, not only as a return type of an operation but also of an attribute. (For example, a document.ready promise would probably be a Promise<void> if spec'd.) The first sentence should indeed be updated to account for promises. It should probably also be updated to account for things like callback function's return type, considering callback functions are not operations per se.

[bathos]

Thanks! Makes sense. I think I was reading ‘as the return type’ without realizing that it was referring to the ReturnType production, and yes, ‘of an operation’ seems incorrect even without Promise in the mix.

[annevk]

I suspect we'd not want Promise<void> for an attribute that's not readonly.

And yeah, callbacks definitely need to be able to return void.

[bzbarsky]

Honestly, there aren't any use cases I've seen so far for a Promise-typed writable attribute at all.

I just checked and there aren't any such attributes in Gecko's IDL, at least.

[Ms2ger]

That's good, because the spec already says:

Attributes whose type is a promise type must be read only.

since #217.

[bzbarsky]

Aha! Turns out, Gecko's IDL parser enforces that too, so no wonder there are no writable promise attributes there. ;)