- Feature Name: n/a
- Start Date: 2015-03-15
- RFC PR: rust-lang/rfcs#979
- Rust Issue: rust-lang/rust#23911
Summary
Make the count
parameterSliceExt::splitn
, StrExt::splitn
and corresponding
Motivation
The majority of other languagescount
parameter
Detailed design設計(する)
Currently splitn
uses the count
parameter
The simplest change we can make is to decrementfinished
. See Unresolved questions for nicer transition paths.
Example usage
Strings
Slices
Languages言語 where count
is the maximum number of items returned
C#
"a,b,c".Split(new char[] {','}, 2)
// ["a", "b,c"]
Clojure
(clojure.string/split "a,b,c" #"," 2)
;; ["a" "b,c"]
Go
strings.SplitN("a,b,c", ",", 2)
// [a b,c]
Java
"a,b,c".split(",", 2);
// ["a", "b,c"]
Ruby
"a,b,c".split(',', 2)
# ["a", "b,c"]
Perl
split(",", "a,b,c", 2)
# ['a', 'b,c']
Languages言語 where count
is the maximum number of times the separator will be matched一致する、マッチさせる
Python
"a,b,c".split(',', 2)
# ['a', 'b', 'c']
Swift
split("a,b,c", { $0 == "," }, maxSplit: 2)
// ["a", "b", "c"]
Drawbacks
Changing the meaning of the count
parameter
The iterator can only return 2^64 values; previously we could return 2^64 + 1. This could also be considered
Alternatives
-
Keep the status quo. People migrating from many other languages
言語will continue to be surprised. -
Add a parallel set
セットする、集合of functions that clearly indicate thatcount
is the maximum number of items that can be returned.
Unresolved questions
Is there a nicer way to change the behaviorcount
such that users of splitn
get compile-time errors when migrating?
-
Add a dummy parameter,
仮引数and mark the methods unstable. Remove the parameterand re-mark as stable near the end of the beta period. -
Move the methods from
SliceExt
andStrExt
to a new trait that needs to be manually imported. After the transition, move the methods back and deprecate the trait. This would not break user code that migrated to the new semantic.