[String] Split method overloaddefinitions order causes error

[lucdekens]

The Split method shows OverloadDefinitions in this order
OverloadDefinitions

string[] Split(char separator)
string[] Split(char separator, System.StringSplitOptions options)
string[] Split(char separator, int count, System.StringSplitOptions options)
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string separator)
string[] Split(string separator, System.StringSplitOptions options)
string[] Split(string separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

When one tries to use the Count parameter, it is first interpreted as a System.StringSplitOptions value.
Since enum values are [int] under the cover I guess.

As a result, this $t.Split(' ',6) will produce the following error:

Cannot convert argument "options", with value: "6", for "Split" to type "System.StringSplitOptions": "Cannot convert value "6" to type
"System.StringSplitOptions" due to enumeration values that are not valid. Specify one of the following enumeration values and try again. The
possible enumeration values are "None,RemoveEmptyEntries"."
At line:1 char:1

• $t.split(' ',6)

•   + CategoryInfo          : NotSpecified: (:) [], MethodException
    + FullyQualifiedErrorId : MethodArgumentConversionInvalidCastArgument
  
  

When the Count parameter is cast to [int], no issue ($t.Split(' ',[int]6)

In PS v5.1, the overloaddefinitions have a different order, and this issue doesn't appear.
OverloadDefinitions

string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)

The Crontab demo module experiences this error as well in line 38 in Crontab.psm1.

I tested with v6.0.0-alpha.13

[lzybkr]

We will likely have to call this by design.

It looks like .Net added some overloads to String.Split - I've listed the interesting ones here:

string[] Split(char[] separator, int count)
string[] Split(string separator, System.StringSplitOptions options)

The second one is new. PowerShell ranks conversions of each argument to try and disambiguate which overload you really meant.

Because PowerShell tries extra hard to convert anything to anything, we needed a way to disambiguate overloads in a reasonable way that felt natural. After analyzing many different overloaded apis, we found that method parameters are typically specified in order of decreasing importance, so we decided that we would weight the conversion rankings in a similar manner.

In your example, we have arguments string, int and are attempting to match char[], int and string, StringSplitOptions.

Because we weight the first parameter/argument higher than the second and because the first argument is an exact match, we attempt to call this new overload.

So I'm not sure there is a good solution. If PowerShell had a character literal, that might help.

[lucdekens]

Thanks Jason, I can live with that explanation, sounds indeed "by design".
And besides casting, to force the intended overload, I can't think of a good solution either.

But it can cause some not-so-obvious errors.

The Crontab demo module (line 38 in Crontab.psm1) suffers from such an error for example.
At least the Crontab demo would need to be corrected.

[lzybkr]

Fortunately the -split operator avoids the need for a cast.

Thanks for reporting the error in crontab - here is the fix: #2796