The tuple leads to a unsound type, it also breaks the already existing allSettled pattern

[gabrielricardourbina]

Using a tuple as a result of this operator is a mistake.

JS allows promises to be rejected with any type, it also allows promises to be resolved with any type

The tuple cannot guarantee that is possible to know if the given promise failed or passed

For example

const [result, error] ?= await Promise.reject(undefined)

const [result, error] ?= await Promise.resolve(undefined)

Without knowing the implementation there is no guaranteed way of knowing if the promise failed or passed,

This has already been solved by Promise.allSettled

This new syntax must be syntactic sugar for this helper function

async function settled(promise) {
  const [settled] = await Promise.allSettled([promise])
  return settled
}

Addendum

As per #27 (comment), the structure of the resulting object might need to be different from the PromiseSettledResult for synchronous functions, although I don't mind using the same type

[gabrielricardourbina]

See #3 (comment)

[arthurfiorette]

The allSettled pattern is just for promises, status: 'fulfilled', and status: 'rejected' is as well.

[gabrielricardourbina]

@arthurfiorette You're right, I'm overlooking sync functions, in any case it has to be a discriminable object.

Personally I don't mind using the same type as Promise.allSettled for sync functions

[arthurfiorette]

It also doesn't have to be an object, falsy throwns are catched by the implementation too, i just didn't added it to the written spec yet because i wanted to see other solutions.

https://github.com/arthurfiorette/tuple-it/blob/32dc86108ae76e5c118bedf320c574c6ac8d6e41/index.js#L13