为什么“Split”不是 Go 中“string”类型的成员函数？

Question

当您想要使用不同语言的特定定界符拆分字符串时，这里有一些片段：# pythons = 'a,b,c,d,e'tokens = s.split(',')// javascriptlet s = 'a,b,c,d,e'let tokens = s.split(',')// gos := "a,b,c,d,e"tokens := strings.Split(s, ",")可以看到，split在Python和Javascript中是string类型的成员函数，在Go中不是。我想知道为什么，它看起来像 CPP 中的 STL，为什么操作类型实例的函数不是该类型的成员函数，在 Go 中实现它们似乎很容易，例如：// gofunc (s *string) Split(d string) []string {  // here goes the code to split s with d given}这样设计的原因是什么？

Answer 1

可以看到，split在python和javascript中是string类型的成员函数，在golang中不是。

这似乎从一开始就是如此：提交 729bc5c，2008 年 9 月，因为 Go1是第一个提到string Split()函数的提交。

基本的字符串实用程序。

这些函数被认为是“实用程序”，而不是预先声明的字符串类型“ string”本身的一部分。

不久之后，它在2009 年 3 月的提交 0f7306b 中被记录下来，仍然是 Go1

// Split returns the array representing the substrings of s separated by string sep. Adjacent

// occurrences of sep produce empty substrings.  If sep is empty, it is the same as Explode.

func Split(s, sep string) []string {

您可以在 2009 年 4 月的提交 5eae3b2中看到它首次使用func LookPath(file string) (string, *os.Error) {

字节与字节使用相同的方法：提交 7893322，2009 年 6 月；Go1，具有类似的 Split() 功能。

添加一个类似于字符串包的字节包。

总体思路是：您可以在不更改值类型本身的情况下更改该效用函数。
参见提交 30533d6，2009 年 6 月：

更改strings.Split,bytes.Split以采用最大子字符串count参数。

func Split(s, sep []byte, n int) [][]byte

更剧烈的演变：提交 ebb1566，2011 年 6 月

strings.Split: 默认拆分所有。
假设完全拆分，将 Split 的签名更改为没有计数，并将Split具有计数的现有重命名为SplitN.

另一个想法是继续使用string，同时可能在不需要时删除对这些实用程序函数的依赖项（如2009 年 11 月提交的 35ace1d中：“删除对strconv和的依赖项strings”）

它还允许添加更多相关功能，而无需触及字符串本身。
请参阅提交 5d436b9，2009 年 11 月：lines := strings.SplitAfter(text, "\n", 0)，它使用Split().

另一个优势：您可以独立优化这些函数string，允许将重复的“拆分”函数替换为strings.Split().
参见提交 f388119，2013 年 3 月，Go 1.1

go/printer: 使用strings.Split而不是专用代码

使用更快的字符串包，专用代码和 strings.Split 之间的区别在于噪音：

benchmark         old ns/op    new ns/op    delta
BenchmarkPrint     16724291     16686729   -0.22%

相反的情况也是如此：用更简单的代码替换 strings.Split，如提交 d0c9b40，2015 年 9 月，Go 1.6

mime：删除字解码中的分配。

这通过用简单的前缀/后缀检查和一些自定义切片替换调用来修复TODOin 。(*WordDecoder).Decodestrings.Split

基准测试结果：

benchmark                    old ns/op     new ns/op     delta
BenchmarkQEncodeWord-8       740           693           -6.35%
BenchmarkQDecodeWord-8       1291          727           -43.69%
BenchmarkQDecodeHeader-8     1194          767           -35.76%

（同样的想法在提交 ecff943，2017 年 9 月，Go 1.11）