val numbers = string.split(";".toRegex())
//gives: [1,2,3,]
尾随空字符串包含在CharSequence.split的结果中.
另一方面,如果我们看一下Java Strings,结果会有所不同：
val numbers2 = (string as java.lang.String).split(";")
//gives: [1,3]
这次,使用java.lang.String.split,结果不包括尾随空字符串.这个行为实际上是给定相应的JavaDoc：
This method works as if by invoking the two-argument split method with the given expression and a limit argument of zero. Trailing empty strings are therefore not included in the resulting array.
但是在Kotlin的版本中,0也是默认的限制参数,如here所述,但当java.util.regex.Pattern :: split为called时,内部Kotlin将该值映射为负值-1：
nativePattern.split(input,if (limit == 0) -1 else limit).asList()
它似乎按预期工作但我想知道为什么该语言似乎限制Java API,因为不再提供0的限制.
解决方法
考虑一个字符串a：b：c：d：和一个模式：.
看看我们在Java中可以拥有的东西：
限制< 0→[a,b,c,d,]
limit = 0→[a,d]
limit = 1→[a：b：c：d：]
limit = 2→[a,b：c：d：]
limit = 3→[a,c：d：]
limit = 4→[a,d：]
limit = 5→[a,](与限制< 0相同)
limit = 6→[a,]
…
似乎limit = 0选项有点独特：它具有尾随：既不替换为附加条目,也不是限制< 0或限制> = 5,也不保留在最后生成的项目中(与1..4中的限制一样).
在我看来,Kotlin API在这里提高了一致性：在某种意义上,没有特殊情况会丢失关于最后一个分隔符后跟一个空字符串的信息 – 它作为最后一个结果项中的分隔符留在原位或者作为一个尾随的空条目.
IMO,Kotlin函数似乎更适合principle of least astonishment.相反,java.lang.String.split中的零限制看起来更像是修改方法语义的特殊值.负值也是如此,显然没有直观意义作为限制,如果不挖掘Javadoc就不太清楚.
