Justin Christensen

> Isn't takeUpto expressible via takeWhile ? You'd need to just negate the predicate, right? No, look at breakOn more closely. takeUpto might not be the right name for it....

@mrkkrp Only do that if you're still on the fence about whether or not to add it. If you don't like the idea, I'm good with closing this.

@js-choi I don't have the full context on the history of this, but there's been a lot of reference made recently to a first-blush impression of one of the JS...

Really, given the size and importance of a language like JS, and the scope of the proposed changes, it shouldn't be out of bounds to get a general idea of...

@mAAdhaTTah They don't need to. I suggested reaching out to the those that have already done this for other languages, and not JS engine implementers.

@mAAdhaTTah Also, the precise stage of a proposal shouldn't matter in the slightest if it's being weighed as a real option against another proposal that is on the same track...

@mAAdhaTTah Ah. Proper function composition, rather than this pipe operator, would address that concern: ``` // no extra closures c = a(1) >> b(2); ``` But I see now that...

Maybe what should be being discussed is function composition, and not pipe. Some of the posts I've seen make reference to the fact that composition can be implemented in terms...

I've got a potential fix for this, and issues like it, here: #617 There's a linked issue where I gave a rundown on what I think is happening.

@nlf Sorry to ping you out of the blue, but this issue has been open for 11 days now without any movement. Is there anyone working on npm right now...