Seeking clarification on whether unioning promises and callbacks is allowed

[sanketj]

While trying to make some IDL updates to the ClipboardItem constructor in Chromium (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/clipboard/clipboard_item.idl), we discovered that the Chromium IDL compiler failed to union a promise and callback, or even just multiple promises, together. We tried a few other cases where we unioned promises and/or callbacks with other types, and those seemed to work. Below is a list of what did work and what didn't.

typedef Promise<Blob> ClipboardBlobPromise;
typedef Promise<DOMString> ClipboardStringPromise;
callback ClipboardBlobCallback = Blob();
callback ClipboardStringCallback = DOMString();

typedef (Blob or DOMString) ClipboardItemData; // works
typedef (ClipboardBlobPromise or DOMString) ClipboardItemData; // works
typedef (Blob or ClipboardStringPromise) ClipboardItemData; // works
typedef (ClipboardBlobPromise or ClipboardStringPromise) ClipboardItemData; // does not work
typedef (Blob or ClipboardStringCallback) ClipboardItemData; // works
typedef (ClipboardBlobCallback or DOMString) ClipboardItemData; // works
typedef (ClipboardBlobCallback or ClipboardStringCallback) ClipboardItemData; // works
typedef (ClipboardBlobPromise or ClipboardBlobCallback) ClipboardItemData; // does not work

constructor(record<DOMString, ClipboardItemData> items);

Based on the above examples that do work, as well as reading through the WebIDL spec, it does not look like there should be any limitations on callback function types or promise types participating in unions. Does this sound like a bug in the Chromium WebIDL compiler, or is there anything in the spec that should prevent such cases from working?

cc: @snianu, @anaskim

[bathos]

Promise types are indistinguishable from every type and thus cannot be members of unions, at least as currently specified. This follows from the fact that e.g. 3 is a valid ECMAScript input for Promise<byte> — it’s like await 3 or Promise.resolve(3).

This issue about possibly changing the ES→WI conversion of Promise<T> to special case functions may be of interest, but that’s about whether to assume any callable input wants to be called in this scenario (e.g. async functions) for the ergonomic benefit.

Note that while (Promise<Blob> or Promise<DOMString> or Promise<SomeCallback>) is incoherent, Promise<(Blob or DOMString or SomeCallback)> isn’t. For similar reasons, two different callbacks cannot be members of one union, but one callback that returns the union of the return types would be fine:

callback ClipboardCallback = (Blob or DOMString) ();

These two “works” cases from above imply errors in Blink’s implementation because these are invalid Web IDL types which don’t have defined conversion behavior:

typedef (Blob or ClipboardStringPromise) ClipboardItemData; // works
typedef (ClipboardBlobCallback or ClipboardStringCallback) ClipboardItemData; // works

(I’m assuming that typedef Promise ClipboardBlobPromise (etc) were meant to say typedef Promise<Blob> ClipboardBlobPromise)

---

It sounds like you might want something like this? —

typedef (Blob or DOMString) ClipboardItemValue;
typedef Promise<(ClipboardItemValue or ClipboardItemValueCallback)> ClipboardItemInit;

callback ClipboardItemValueCallback = ClipboardItemValue ();

// ...
constructor(record<DOMString, ClipboardItemInit> items);

[sanketj]

Yes, I did mean typedef Promise<Blob> ClipboardBlobPromise instead of typedef Promise ClipboardBlobPromise. I've fixed that in the original post too.

Thanks for the clarifications @bathos! Those explanations all make sense.