Now that it is possible to get the characters of a string using String.chars, it is no longer needed to hack that using str.split(""), which was a surprising behavior anyway. So disallow an empty separator for String.split. (This is consistent with Python.)
Now that there is String.chars, it would be nice if str.chars().len() == str.len() were always true. The UTF-8 byte length of a string makes sense for a low-level language with mutable buffers like Rust, but not for a high-level language with immutable strings like RCL. So it makes more sense to me to count code points than bytes, even if it is O(n). If it turns out to be a bottleneck later there are many things we could do to optimize (cache the length, special-case ASCII strings, etc.). But so far I suspect it’s not even needed.
[x] Ensure documentation is up to date.
[x] Ensure test coverage.
[x] Ensure the fuzzer discovers the new methods and cases.
Add the following methods:
String.starts_withString.ends_withString.containsString.charsNow that it is possible to get the characters of a string using
String.chars, it is no longer needed to hack that usingstr.split(""), which was a surprising behavior anyway. So disallow an empty separator forString.split. (This is consistent with Python.)Now that there is
String.chars, it would be nice ifstr.chars().len() == str.len()were always true. The UTF-8 byte length of a string makes sense for a low-level language with mutable buffers like Rust, but not for a high-level language with immutable strings like RCL. So it makes more sense to me to count code points than bytes, even if it is O(n). If it turns out to be a bottleneck later there are many things we could do to optimize (cache the length, special-case ASCII strings, etc.). But so far I suspect it’s not even needed.