Pick an initial set of combinators and defend them

[domenic]

The explainer claims

In any case it is important to realize that operators are not the meat of this proposal, as thy could conceivably follow along at any time provided there is support for the actual native Observable API, which is what this proposal principally focuses on.

I disagree. Without a good set of combinators, observables wouldn't be worth shipping. If you're pulling in a combinator library anyway, then you might as well pull in an observable library.

I think this explainer should pick an initial set of combinators and defend them. I think the list drawn from the iterator helpers proposal is good. You should then:

• Make sure all your examples only use combinators in that list
• Include them in the IDL block / observable API section
• Be clear which are promise-returning (and thus suffer from "Concerns") vs. not
• Figure out if there are any that are not from iterator helpers, but are a really good idea for observable-specific reasons. E.g., first().
• Relegate discussion about expanding the set to an appendix. Perhaps, stress that you'd prefer to follow the lead of the rest of the platform, e.g. TC39's designs for iterators and arrays, similar to how web platform maplikes and setlikes follow TC39's designs for Maps and Sets.

[domfarolino]

This is great advice, in particular the last point about following TC39's lead and the corresponding examples, thanks! I think I've incorporated this feedback into the explainer with the last several commits, so I'll close this now.