Forbid overloading operations with Promise and non-Promise return types.

[Ms2ger]

Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25051.

---

Preview | Diff

[domenic]

This seems reasonable but I wonder if https://www.w3.org/Bugs/Public/show_bug.cgi?id=25051 has more to it. In particular the sentence @bzbarsky quotes there remains, and e.g. for void/Window overloads (like document.open), "the return type" is still problematic.

As such I'll leave @bzbarsky to give approval on the best approach here. (But thanks for tackling old issue-tracker issues!!)

[bzbarsky]

We should probably go through the uses of the "return type" concept in the spec and see what they actually want. Maybe we should actually have a "set of return types". For example, the [NewObject] requirement around "return type" should probably apply to all the return types for all the overloads.

We could then require that all the types in the set either are or are not promise types and switch on that boolean in the operation steps that check for promise return type.

In general, it seems we use "return type" in the following normative language:

• Discussion about where void can be used, at https://heycam.github.io/webidl/#idl-void
• [NewObject] bits
• https://heycam.github.io/webidl/#dfn-create-operation-function
• https://heycam.github.io/webidl/#es-default-tojson which is not really using the concept
• https://heycam.github.io/webidl/#legacy-platform-object-delete for named deleters (which I would hope can't be overloaded!)
• https://heycam.github.io/webidl/#call-a-user-objects-operation (can this be overloadead? I don't think that makes sense in practice, but not sure whether it's explicitly forbidden).
• https://heycam.github.io/webidl/#es-invoking-callback-functions -- no overloads here
• https://heycam.github.io/webidl/#construct-a-callback-function -- same thing

I think that's it.

I'm happy to solve the promise-vs-not problem for a start, because I think that's the only "real" problem here in practice, or have a slightly more extensive refactoring if desired.

[Ms2ger]

We're generally not clear on whether an "operation" is a single signature or a set of signature; that also causes issues in the loop over all operations in define the operations, for example. I'd like to untangle it all at some point, but not in this PR.

[ExE-Boss]

It should also be disallowed to have Promise and non‑Promise types in a union of a return type.

[bzbarsky]

See https://heycam.github.io/webidl/#dfn-distinguishable and "Example 27" following it.

[domenic]

Let's merge this and spin off a separate issue for examining the "return type" problem generally.