Exposing `resolve` and `reject`

[Valery Zinchenko]

Why having a new method like Promise.withResolvers if we could expose resolve and reject instead?
Also resolve and reject can be exposed as getters to avoid modification.

I'm not sure about consequences, but something tells me it's okay to do so since they were private and now they are public - no interference. Using traditional method or Promise.withResolvers will do the same staff anyway.

Example

Instead of

const { promise, resolve, reject } = Promise.withResolvers();

We will get

const promise = new Promise();
promise.resolve(...);
promise.reject(...);

[Kevin Gibbons]

See previous discussion.

Putting properties on the Promise itself means that the ability to read the Promise is conflated with the ability to write to the Promise, which is a very bad idea.

[Valery Zinchenko]

See previous discussion.

Putting properties on the Promise itself means that the ability to read the Promise is conflated with the ability to write to the Promise, which is a very bad idea.

I see, but as I proposed we can expose these resolvers as getters and as this would be a native implementation, the functions will be [native code], so I don't see any reasons why this is a very bad idea since everything still encapsulated.

I'm sorry to ask for that, but I didn't find any real reason to not add it like I proposed, could you mention some comments for me so I could read? I see that you're into this more than me.

[Kevin Gibbons]

The point is that code which needs the ability to read a Promise does not usually need the ability to write to the Promise, and giving things more power than they need leads to complicated and fragile systems. Keeping those two abilities separate makes it much easier to reason about code.

[Valery Zinchenko]

The point is that code which needs the ability to read a Promise does not usually need the ability to write to the Promise, and giving things more power than they need leads to complicated and fragile systems. Keeping those two abilities separate makes it much easier to reason about code.

1. We have only two methods with a concise purpose
2. Developers are anyway deconstructing Promises

So what is complicated and fragile here?

If we keep these systems separate to reason better about the code, why we need native implementation of what is not harder to maintain and worse for understanding a code?
Not to say that it's already done by numerous libraries and just takes two-three lines to deconstruct a Promise.

I'm not proposing to change a lot, just to add two getters resolve and reject, which will not cause any misunderstanding and will take very little effort to implement. Again, I'm not proposing to have possibility to write to the promise but read its resolvers.

[Kevin Gibbons]

So what is complicated and fragile here?

What is complicated and fragile here is that the change you propose would mean that every Promise would carry the ability to write to it alongside the ability to read to it.

I'm not proposing to change a lot, just to add two getters resolve and reject, which will not cause any misunderstanding and will take very little effort to implement.

I didn't say it would cause misunderstandings or be difficult to implement, so I'm not sure why you're bringing those up.

Again, I'm not proposing to have possibility to write to the promise but read its resolvers.

The ability to read a Promise's resolvers is the ability to write to the Promise.

I don't think I can say this any more clearly, so I'm going to step away now. In any case, we are definitely not going to make the change you propose. Maybe someone else can explain why more clearly than I have.

[Valery Zinchenko]

I didn't say it would cause misunderstandings or be difficult to implement, so I'm not sure why you're bringing those up.

Sorry for taking something different from your arguments.

The ability to read a Promise's resolvers is the ability to write to the Promise.

Now I seem to understand the problem, thanks. I think you're referring to writing to state and result of a Promise with reject and resolve.

I don't think I can say this any more clearly, so I'm going to step away now

You could say it more clearly by mentioning "writing to state and result" not by just repeating the same words multiple times.

[Valery Zinchenko]

I see the only concern in revealing resolve and reject for Promise that they will be exposed for every Promise, but we would like to separate intentions with withResolvers. It's not actually about writing to a promise because withResolvers will expose resolve and reject, which will give us the same opportunity to "write" to the promise.

[Peter Klecha]

right, what @bakkot was talking about was the possibility of writing to the internal state of the promise by calling resolve or reject.

and yes it's true that any user could, for example, attach the resolve and reject functions to the promise themselves and create the situation which @bakkot is trying to avoid. that's also true today pre-withResolvers. The point of withResolvers is to increase convenience for a well-established and non-dangerous pattern -- namely calling resolve and reject after getting a handle on the promise. The alternative proposed here is considered a less-well-established and more dangerous pattern, so the committee is not going forward with it. This has already been settled in committee. Being at Stage 3, the current proposal will not change unless motivated by significant web compatibility, security, or performance concerns.