You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I mentioned in #6, I hesitate to extend the API for methods that are merely shorthand. However, in this case I am definitely open to the possibility of adding a fn substring_from_start(index: usize) -> &str and fn substring_to_end(index: usize) -> &str to perform s.substring(0, index) and s.substring(index, s.len()) respectively. My main interest is whether these might be more optimal in certain cases. Specifically, I suspect that something like s.substring(1, s.len()) might be slightly slower than s.substring_to_end(1), do to avoiding iterating through the char_indices all the way to the end. For sufficiently large s, that may have a significant speed increase.
I'm not sure exactly what the magnitude of such an increase would be, though. I intend to set up some benchmarks to experiment. Whenever I get around to that, I can evaluate whether such an extension to the API is worth it.
Quick update on this: support for this feature is on its way through the pipeline, and will be live in version 2.0.0. It isn't implemented exactly as discussed here, but I think the way it is implemented is actually far easier to use, since it just relies on an index value implementing RangeBounds<usize>, which gives all kinds of freedom that wouldn't be available otherwise.
See #9 for more details on the change, and #11 for the actual PR containing the change.
I'll close this issue when it is merged into master.
Should be able to exclude len() for example:
string.substring_len(3)
Could be a shorthand for
string.substring(3, string.len())
The text was updated successfully, but these errors were encountered: