- From: Boris Zbarsky <notifications@github.com>
- Date: Mon, 26 Aug 2019 09:28:58 -0700
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/pull/776/c524929243@github.com>
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/pull/776#issuecomment-524929243
Received on Monday, 26 August 2019 16:29:21 UTC