Bikeshed: next/complete/error vs. other names

[domenic]

I suspect this has been discussed in the literature before, so I apologize for re-raising it. But it would be worthwhile to document it somewhere in the explainer.

Basically, are next/complete/error the best names? Ones that immediately come to mind from a JS language design perspective are next/return/throw. There's also an argument to be made for yield/return/throw.

One related idea to keep in mind is how promises chose resolve|fullfill / reject, instead of return / throw. There are a few reasons for this:

• The subtle differences between resolve and fulfill meant neither was a great map onto "return".
• Back in the days of ES3 when Promises/A+ was first being created, you couldn't use keywords like throw/return as property names, so instead of Promise["throw"]() we did Promise.reject().
  • Even today, it'd be annoying to have to do new Promise((rreturn, tthrow) => { ... }) to avoid the still-existing prohibition on using keywords as variable names.
• Keeping the namespaces distinct helps give us a short vocabulary to talk about "async throwing" and "async returning", with the single words "rejecting" and "resolving".

I'm not sure any of those arguments are super-compelling, but maybe they set a historical precedent.

[benlesh]

From my perspective, I'm amenable to anything here, just so long as it's not something that would require a breaking change for RxJS or other existing implementations.

In other words: So long as we're not naming something next, error, or complete and then wildly changing the arguments, I think it's fine. I want to have a pathway to migrate people off of RxJS to whatever lands here whenever that makes sense.

[domenic]

Having thought about this more, I think we should generally bias towards sticking with community precedent. But to that end two things would be especially helpful:

• How strong is the community precedent? #8 is related, but also discussing other languages would be helpful data here.

• Has this question ever been discussed in the community before? (Or maybe in previous standardization attempts?) It would feel better if the story for the community names was not "someone came up with them in the dawn of time by themselves, and nobody ever thought to question the results."

[benlesh]

How strong is community precedent?

Honestly stronger than I thought (and you know I'm bullish on this)... I added only the most prominent examples here: https://github.com/domfarolino/observable/pull/23

But if you do a GitHub search for JavaScript or TypeScript code that references Symbol.observable, or @@observable, or symbol-observable, it bubbles up a lot of code that is using as same-shaped observable.

[domfarolino]

The only prior discussion related to renaming these that I could find in the TC39 repo was https://github.com/tc39/proposal-observable/issues/185, which was more than just a simple rename, but rather an attempt to coalesce "error" and "complete" into a single method.

Otherwise, I don't see much discussion about this in the past, and people seem to like the current names established by community precedent so I think I'll close. We can revisit this if there is a stronger community-driven motivation to rename these perhaps.