const value = fn();
Promise.resolve(value);

bakkot: the problem I'm concerned about is one of maintainability rather than performance. for the "making something non-promisey work with promises" usecase, the optimal implementation from a maintainability perspective is one that is a) self-contained and b) minimal; that is, you'd be using new Promise, and its body would contain only the minimal wiring necessary to convert some other non-standard async API into a Promise. that way, the conversion itself can be entirely agnostic to the business logic, and all the actual business logic would exist in a 'safe' Promise-y context (ie. benefiting from the Promise error handling behaviour such as automatic propagation)

this already gets done wrong a lot due to lacking documentation on working with Promises, in that a lot of people tend to put additional business logic within the new Promise, sometimes nesting several levels of (unsafe) async callbacks before eventually resolving/rejecting something, or adding needless complexity by eg. having promise chains nested within a new Promise. but in this case, at least the design of the API encourages keeping resolve/reject logic within that callback - so the problem is usually contained to just the contents of the new Promise callback, which makes it easier to fix.

the problem with a defer API, then, is that the pattern it encourages is "pass your promise to one place, and your resolve/reject functions to another", which I've already seen lead to people passing resolve/reject functions through sometimes multiple layers of indirection (all of them using 'unsafe' async patterns), ending up with a huge pile of spaghetti async code that's nearly impossible to reason about or untangle even when you want to fix it. unlike with the new Promise API, there's nothing that 'nudges' people towards keeping it contained within a single place.

(note: I'm currently sick and someone down the street seems to have just decided to start hammering something again, so I hope that all makes sense, and I don't know how long I can keep being engaged in this discussion for)

for the "making something non-promisey work with promises" usecase, the optimal implementation from a maintainability perspective is one that is a) self-contained and b) minimal; that is, you'd be using new Promise, and its body would contain only the minimal wiring necessary to convert some other non-standard async API into a Promise

hm, I think I do not agree with this, or rather I agree in theory if the wiring happens to be cleanly expressed that way (say your sync API is in the ((val, err) => body callback style) but that in many cases the wiring does happen to work out cleanly that way (say an event emitter style, where only certain events or events under particular conditions should be the trigger for the promise settling, and the other cases you're doing something else). this is kind of what your next paragraph gets at:

this already gets done wrong a lot due to lacking documentation on working with Promises, in that a lot of people tend to put additional business logic within the new Promise

I think this is actually encouraged by the design of the Promise constructor, and part of the point of this proposal would be to make it easier to not do that. in my experience the business logic is often pretty entangled with the wiring, and can't be cleanly separated - if you only want to settle after a certain number of events, say, then the current design means that the "business" logic which counts the events has to go inside of the callback to the Promise constructor (or you have to a Promise.defer-style helper), so that it has access to resolve.

which I've already seen lead to people passing resolve/reject functions through sometimes multiple layers of indirection (all of them using 'unsafe' async patterns), ending up with a huge pile of spaghetti async code that's nearly impossible to reason about or untangle even when you want to fix it

that does seem like a bad outcome, thanks for the example.

note: I'm currently sick and someone down the street seems to have just decided to start hammering something again, so I hope that all makes sense, and I don't know how long I can keep being engaged in this discussion for

yeah, no worries, if this does become a proposal there will be plenty of time to comment at that point

I think this is actually encouraged by the design of the Promise constructor, and part of the point of this proposal would be to make it easier to not do that. in my experience the business logic is often pretty entangled with the wiring, and can't be cleanly separated - if you only want to settle after a certain number of events, say, then the current design means that the "business" logic which counts the events has to go inside of the callback to the Promise constructor (or you have to a Promise.defer-style helper), so that it has access to resolve.

to clarify, I would consider "counting the events" in that example to be part of the wiring logic, not the business logic, as it is necessary for the wiring the function - and therefore it belongs within the new Promise constructor. with "business logic" I am really referring to things that have nothing to do with the wiring, eg. subsequent transformations of the resolved value, multiple underlying asynchronous operations, that sort of thing.

this is not the greatest example, but it happens to be from yesterday so I still have it in my history: https://bpa.st/RZVQ#1L41 -- neither the Promise.all nor the JSON.parse/IrcBookState.FromJson logic really belongs inside of that new Promise, as both are business logic unrelated to wiring up non-Promise async APIs into a Promise. now in this specific case, there is no useful wiring within the new Promise callback and that shouldn't have been used at all, hence why it's not a great example :)

joepie91 🏳️‍🌈: yeah, so, I feel like again the "there is too much stuff inside of new Promise" thing is a consequence of the design of the Promise constructor, and would be improved by Promise.defer in many cases.

like, to talk a little more concretely, consider the case of an event emitter which emits a series of chunks and then a done event. you could promise-ify it in a few different ways:

let emitter = makeChunkEmitter();
let chunks = [];
emitter.on('chunk', chunk => chunks.push(chunk));
return new Promise(resolve => emitter.on('done', () => resolve(chunks)));

which has the problem that the two on calls are weirdly separated, which makes it hard to follow, or

let emitter = makeChunkEmitter();
return new Promise(resolve => {
  let chunks = [];
  emitter.on('chunk', chunk => chunks.push(chunk));
  emitter.on('done', () => resolve(chunks))
});

which has the problem that there is logic unrelated to promise resolution inside of the call to the Promise constructor, and that if emitter is null it will incorrectly put the error inside of the Promise even though the problem wasn't inside of the emitter itself at all, or

let emitter = makeChunkEmitter();
let { resolve, promise } = Promise.defer();
let chunks = [];
emitter.on('chunk', chunk => chunks.push(chunk));
emitter.on('done', () => resolve(chunks));
return promise;

which I think is the cleanest, but which has the problem that Promise.defer does not exist.