Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow functions to be used as promise inputs #1020

Open
domenic opened this issue Sep 7, 2021 · 9 comments
Open

Allow functions to be used as promise inputs #1020

domenic opened this issue Sep 7, 2021 · 9 comments

Comments

@domenic
Copy link
Member

domenic commented Sep 7, 2021

See WICG/navigation-api#40 for background.

Basically, any time we convert an ES value to a Promise<T>, we should first check to see if it's a function. If so, we should call the function, and use its return value.

This allows code such as

event.waitUntil((async () => {
  // ...
})());

to become

event.waitUntil(async () => {
  // ...
});

This would be backward-compatible since there is no existing instances of Promise<T> where T is a callback function type, that are used as inputs.

@bakkot
Copy link
Contributor

bakkot commented Sep 7, 2021

Re: waiting for async-do: I am no longer confident I'll get async-do to stage 3 within the next ~6 months. I'm still holding out hope for within a year, though. (There's some irritating complexity in the design of do-expressions which is slowing it down, and unfortunately for personal reasons I haven't been able to dedicate as much time as I'd like for the past few months.)

@annevk
Copy link
Member

annevk commented Sep 8, 2021

This would mean that something like Promise.resolve() cannot be expressed through Web IDL.

It does seem useful as it's the kind of code you would expect to work, but I worry about the mismatch with JavaScript in general becoming a problem for developers as they would have to know about this and the difference between Web IDL and non-Web IDL APIs.

@domenic
Copy link
Member Author

domenic commented Sep 8, 2021

So far the only promise-accepting APIs in JS are the promise combinators themselves, which I think should be exempt from this sort of special-casing. I do think if ES introduces new promise-accepting APIs (although it's hard to imagine what), they should follow the precedent we set here.

@ExE-Boss
Copy link
Contributor

What about a function object that has a then method?

@domenic
Copy link
Member Author

domenic commented Sep 15, 2021

It would be called; the typeof check would happen first.

@ExE-Boss
Copy link
Contributor

@domenic

It would be called; the typeof check would happen first.

That is the opposite of how Promise.resolve(), Promise.all(), Promise.prototype.then, etc. work, which call the then method.

@domenic
Copy link
Member Author

domenic commented Sep 23, 2021

Yes. That's fine.

@ExE-Boss
Copy link
Contributor

APIs that want this should just be able to use:

callback PromiseCallback = Promise<undefined> ();
interface AppHistoryNavigateEvent : Event {
	undefined transitionWhile((Promise<undefined> | PromiseCallback) newNavigationAction);
};

@domenic
Copy link
Member Author

domenic commented Sep 29, 2021

The idea is to do it uniformly for the entire web platform, not as one-offs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants