Race() accepts an empty array

[joshdifabio]

race() currently accepts an empty array, which seems to be a bug.

e8c20be#commitcomment-17349444

[jsor]

See domenic/promises-unwrapping#75

[joshdifabio]

I'm struggling to see the value in the never resolved promise approach, despite the arguments made in the linked discussion, which I think are fairly abstract. Can anyone think of a case that race([]) would happen other than in error? What do you think, @jsor, @clue?

[joshdifabio]

Note that both icicle and amp throw exceptions in such cases:

https://github.com/amphp/amp/blob/v1.1.0/lib/functions.php#L388
https://github.com/icicleio/icicle/blob/v0.9.6/src/Awaitable/functions.php#L301

[jsor]

I'd vote for either

1. Keep race(), make it ES6 compliant and add a warning to the docs (example).
2. Remove race() in 3.0.

[joshdifabio]

I'd vote for either

1. Keep race(), make it ES6 compliant and add a warning to the docs (example).
2. Remove race() in 3.0.

What's the thinking behind removing it?

Edit: The bluebird docs referenced in your post explain your reasoning.

[jsor]

@joshdifabio yes 👍

[clue]

I'm struggling to see the value in the never resolved promise approach, despite the arguments made in the linked discussion, which I think are fairly abstract. Can anyone think of a case that race([]) would happen other than in error?

Personally, I haven't had a use for the race() function so far, but this behavior is surprising to say the least, so it makes perfect sense raising this issue 👍

For bluebird it certainly makes sense to follow ES6. However, this doesn't necessarily apply to this library, considering interoperability with javascript world is a rather moot point.

I'm currently undecided, but I think we should address this somehow, docs could be a first step.

if a necessary feature has a high astonishment factor, it may be necessary to redesign the feature
https://en.wikipedia.org/wiki/Principle_of_least_astonishment

[jsor]

For bluebird it certainly makes sense to follow ES6. However, this doesn't necessarily apply to this library, considering interoperability with javascript world is a rather moot point.

Not sure what you are proposing by "not necessarily follow ES6": remove race or keep it in its current implementation?

[clue]

Giving I have no current use for race(), I'm undecided.

Does removing it altogether really resolve the issue here? :)

My main concern here would be lack of documentation, but I'm good with either solution 👍