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

Question

当您想要使用不同语言的特定定界符拆分字符串时，这里有一些片段：

# python

s = 'a,b,c,d,e'

tokens = s.split(',')

// javascript

let s = 'a,b,c,d,e'

let tokens = s.split(',')

// go

s := "a,b,c,d,e"

tokens := strings.Split(s, ",")

可以看到，split在Python和Javascript中是string类型的成员函数，在Go中不是。我想知道为什么，它看起来像 CPP 中的 STL，为什么操作类型实例的函数不是该类型的成员函数，在 Go 中实现它们似乎很容易，例如：

// go

func (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.1go/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.6mime：删除字解码中的分配。这通过用简单的前缀/后缀检查和一些自定义切片替换调用来修复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）