strings,bytes: improve doc of Split* functions for the empty string case

[dolmen]

In go 1.8 the behaviour of strings.Split{,N,After,AfterN} functions is not explicitly documented for the special case of splitting the empty string "". The functions return a slice with a single element which is the empty string.

The problem is that the Go behaviour is not the same as in other programming languages with functions with a similar name where for the same input the result is a zero-length array.

In Go (playground):

	fmt.Printf("%q\n", strings.SplitAfter("a", ":"))
	fmt.Printf("%q\n", strings.SplitAfter("", ":"))
	// Output:
	// ["a"]
	// [""]

In Perl 5 the result is a zero-length list:

perl -mData::Dumper=Dumper -E 'say Dumper([ split /:/, $_ ]) for "a", ""'
$VAR1 = [
          'a'
        ];

$VAR1 = [];

This leads to wrong expectations from users of the functions (especially when porting code from other languages) and may lead to security issues such as incorrect input validation or deny of service.

The documentation should be improved by documenting specially this corner case.

[gopherbot]

CL https://golang.org/cl/38690 mentions this issue.

[ammario]

I've created a CL addressing this issue by changing the behavior of the Split func to always return a []string{""} if s is empty.

[ianlancetaylor]

The functions have behaved as they do since before the Go 1 release. I think we would need a strong reason to change that behavior, and I don't see that strong reason here. I think we should change the documentation instead.

[mattn]

I think you should not think the go's behavior as same as perl. In javascript, "".split(",").length == 1. python also return 1 with len("".split(",")).

[ammario]

What would be a good message to document it? Something like

// If s is empty, SplitAfterN returns a slice with a single empty string.
// If both s and sep are empty, SplitAfterN returns an empty slice.

seems too verbose to explain such an obscure feature.

[dolmen]

@ammario That's because it is obscure that it must be documented.

[gopherbot]

CL https://golang.org/cl/44950 mentions this issue.