Draft A

[domenic]

I was about to commit this for discussion, before I realized a potentially fatal flaw that made me contemplate Draft B (#2).

---

Promises/A+ Extension: Synchronous Inspection

This proposal extends the Promises/A+ specification to cover synchronous inspection of a promise's fulfillment value or rejection reason.

It is not expected that all Promises/A+ implementors will implement this extension. If the features of this extension are desired, you should test for them as in the "Branding" section below.

Motivation

TODO

Requirements

Branding

An implementation of the synchronous inspection extension must signal that synchronous inspection is available by adding a truthy synchronousInspection property to every then method:

if (promise.then.synchronousInspection) {
  // Proceed to use the properties described below.
}

Synchronous Inspection Properties

1. When pending, a promise
   1. must not have a property named fulfillmentValue.
   2. must not have a property named rejectionReason.
2. When fulfilled, a promise
   1. must have a property named fulfillmentValue, whose value is equal to the promise's fulfillment value.
   2. must not have a property named rejectionReason.
3. When rejected, a promise
   1. must not have a property named fulfillmentValue.
   2. must have a property named rejectionReason, whose value is equal to the promise's rejection reason.
4. If a promise consumer sets a property named fulfillmentValue or rejectionReason, this must not have any impact on the promise's state.

   Suggestions

If feasible, an implementation is encouraged to make fulfillmentValue and rejectionReason properties non-writable, to discourage attempts to set them.

Note

Since fulfillment values and rejection reasons can be any valid JavaScript value, including undefined, this specification hinges on the difference between a property being present and it being absent. That is, the proper way to synchronously test for a promise being fulfilled is not if (promise.fulfillmentValue) or even if (promise.fulfillmentValue !== undefined), but instead if ("fulfillmentValue" in promise).

[domenic]

The fatal flaw with this idea, which is based off of https://github.com/promises-aplus/promises-spec/issues/61#issuecomment-11901800, is that fulfillmentValue and rejectionReason are just ordinary properties. In particular, promise consumers can set them and confuse other consumers.

[novemberborn]

This precludes the implementation of ever freezing the promise.

[domenic]

Yup, thus draft B.

[domenic]

This is inferior to Draft B; closing to prevent confusion from those thinking this is actively being considered for standardization under the Promises/A+ banner, but of course discussion is still welcome.