tc39 / tc39/test262

Explicit asynchronous resolution functions

Open
#848 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
2.8k
Forks
564
Avg merge
3d 7h
Merged PRs (30d)
10

Description

Currently, asynchronous functions signal their completion through the invocation of a globally-defined function named $DONE. This function is used both in passing and failure cases: "completed" tests are interpreted as "passing" or "failing" based on the truthiness of the first parameter.

This behavior enables a pattern that has become common across the tests for Promises: the function may be specified to both arguments of Promise.prototype.then, e.g.

Promise.resolve().then($DONE, $DONE);

In order to account for the expected case, tests have been authored such that promises are resolved with a falsey value. The "implicit failure" mechanism will be triggered if the promises are rejected with some truthy value.

However, if the promises are rejected with a falsey value, these tests will spuriously pass.

To avoid this, I'd like to simplify the implementation of $DONE to only signal a passing test and introduce a new function to signal failure unconditionally. The name $ASYNCERROR would complement the existing $ERROR function, but I'm open to suggestion on that. Such a helper function would also be useful in asserting that "fulfillment" paths are not taken (which was an issue in gh-846, currently under review).

The above example would then look like:

Promise.resolve().then($DONE, $ASYNCERROR);

What do folks here think?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read harness/doneprintHandle.js to understand the current $DONE behavior and sta.js for the existing $ERROR helper. Review the Promise tests using Promise.prototype.then with $DONE in both branches, then define the helper behavior and update those tests so rejection always fails while expected fulfillment passes.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.