GeezerVison

let's use some other char instead of # - it's easy to confuse with comments, but comments are irrelevant here.

also nit: doesn't start

Fixed.

wow didn't know you can do that!

sergei (@vors):
Turns out I didn't know either, mostly because the documentation:

• in part suggests that only string scalars are supported (<String> in the syntax diagram)

• where it does mention arrays (multiple input strings), mistakenly claims that only the binary form supports them ("To split more than one string, use the binary split operator ").

I've created a doc issue to address that.

(I originally thought that when you pass an array it simply gets stringified based on $OFS, but that's not the case.)

Is this a valid scenario, or should PowerShell report an error when the count is less than 1?

I get this from our documentation - see <Max-substrings>.
So it will be a breaking change if we add a exception here. I don't see the need for that.

Michael Klement (@mklement0) Could you please comment too?

Ilya (@iSazonov): Yes, the documentation states "A value of 0 and negative values return all the substrings".

Supporting 0 definitely makes sense, because in order to be able to specify options you must also specify a <max-substrings> value for syntactical reasons, so you need a way to signal the default of "return all".

Negative values serve no real purpose - and could lead people to mistakenly assume that they have special meaning - but given that they're documented and that we could break existing code, I don't think a change is warranted.

Michael Klement (@mklement0) Thanks for good comment!

There is an argument in favor of a breaking change - is a negative count a likely bug? For example, if I compute the count and swapped my operands, this feels like a bug PowerShell should catch.

I do think it's an unlikely breaking change, mostly because the count it most commonly a constant.

I meant something like:

$cnt = $b - $a # Should have been $a - $b
'a b c d' -split ' ', $cnt

Got it, thanks. Preventing negative values categorically is certainly at odds with what I just proposed, but I'd still consider it an improvement.

It is interesting improvement:

PS C:\temp> 'a b c d' -split ' ', 2
a
b c d
PS C:\temp> 'a b c d' -split ' ', 1
a b c d
PS C:\temp> 'a b c d' -split ' ', 0
a
b
c
d
PS C:\temp> 'a b c d' -split ' ', -1
a b c d
PS C:\temp> 'a b c d' -split ' ', -2
a b c
d

Ilya (@iSazonov): Yes, though your -2 behavior is what I suggest for -1 - analogous to index [-1] retrieving the last element of a collection.
Not sure if providing a way to not split at all is necessary.

> 'a b c d' -split ' ', -1  # last 1
a b c
d

> 'a b c d' -split ' ', -2  # last 2
a b
c
d

Also, it's probably worth always returning a first item that represents the remaining, unsplit part - even if that part is empty:

> 'a b' -split ' ', -2  # last 2, with nothing remaining
   # empty string  to signal that there's no remaining part
a
b

That enables the following idiom, irrespective of whether there's a remaining part (prefix) or not.

> $prefix, $tokens = 'a b' -split ' ', -2

Michael Klement (@mklement0) I like the "breaking change". If Jason Shirk (@lzybkr) approve we should open Issue Enhancement.

Multi-line tests should probably all test the three linefeed variants: `n, `r, and `r`n.

Here we is full based on RegEx implementation in our code. We don't parse the string, we only pass it to RegEx as is. Do we really want to test CoreFX implementation?

True today and probably true forever, but if somebody decided they could be smarter than regex (maybe in limited scenarios), it's useful (if it's easy) to cover those additional scenarios.

I see your point. I added tests for 'n' and 'rn'. SingleLine option catch only 'n so I believe no tests needed for 'r'.