Interpretation of count argument

[bathos]

In #3 this was mentioned and it seems to merit its own thread:

It seems to me like Python and JavaScript are the only ones doing the intuitive thing

I agree, I’d also expect the count to refer to the number of splits, not the number of parts including the remainder. I guess this is pretty subjective and may be chiefly dependent on what languages one is accustomed to. However I think there are also some less subjective reasons to use Python's behavior / the existing count semantics:

• having a different interpretation of the count argument between two similarly named methods that do almost the same thing could be a pretty nasty refactoring hazard.
• people will still use split given most usage doesn’t require the count param and the name is familiar, so we’ll end up having to memorize a new arbitrary difference.
• zero is a valid/rational count. positive-integer-but-not-zero seems uncommon in today JS (toPrecision ... any others?).

Re: zero, I’m pretty sure I’m splitting zero things at the moment, so it’d be weird to discover that’s mathematically impossible! Though I’m sure there are plenty of exceptions, when zero is not a valid number-of-things that seems like a hint that something might be off conceptually ... off by one.

[hax]

How to interpret "n", IMO no one side is theoretically more correct than the other.

I slightly prefer non-python way because it seems a little bit easy to reflect it as

let [a, b, c] = s.splitN(3, pattern)

which n = 3 directly mean u get a length = 3 array.

Anyway it will always a point developers need to remember, so I think we'd better just follow the larger party which ease the developers cross the languages. Though python (and js, which interpret n in similar way) is the two most two popular languages , but still the minority.

[bathos]

Anyway it will always a point developers need to remember

One point now; it either stays one point or becomes two points. Instead of "JS does it this way" it'd be "JS does it both ways". The behavior used would depend on whether there's a remainder, which is an unrelated concern, and I think that's pretty confusing.

Though python (and js, which interpret n in similar way) is the two most two popular languages , but still the minority.

I'm not sure that raw quantities of languages decoupled from the context of how and how much their audiences intersect with JS's should matter in this context because it's not a blank slate situation.

[hax]

Yeah we should't have both ways.

But IMO we don't have much choices, if u use regexp with capture group, it will be very clear current split second arg is just broken, and even not match Python interpretation of n.

So either we follow the broken semantic (just split after the nth array elements --- not sure how easy engines could implement like that weird behavior), or it look likes one way but actually introduce two ways in a more subtle style --- only have difference when regexp capture group involved.