str's trim_left and trim_right implicitly assume LTR text #30459
Comments
huonw
added
I-nominated
T-libs-api
|
I seem to recall Android adding |
|
+1 for How does the libs team feel about deprecating stable APIs? |
|
Can confirm: I don't think we need to deprecate these methods. A documentation tweak could clarify the current implications on their behavior. Do we even have a way to detect an RTL configuration anyways? Perhaps this is best left to an external crate to implement these methods as a precursor to a more general localization framework. |
No we don't.
Also, I don't really understand what you mean by an external crate doing this: there is absolutely no intention for these functions to change so to have |
|
I don’t think anything in the standard library should behave differently based on text direction. This stuff is more complex than you might think: http://www.unicode.org/reports/tr9/ (If you really want to do proper text layout, it’s a job for https://github.com/servo/unicode-bidi and other crates.) Left and right in Methods with an |
|
Okay, I see now. The text gets reversed during rendering--in memory the start of the string is at index As for the |
|
Yes, http://www.unicode.org/reports/tr9/#Introduction explains that memory representation of Unicode text is in "logical order" and gives some more details. Ok, |
|
Libs team consensus: for now, we should make sure the documentation is clear about exactly what's happening here. In the long run, we'd be interested in a deprecation/renaming, but we'd like to have some better tools in place to do so. The problem is that if we just deprecate it normally, all crates using the functionality have to choose between deprecation messages and upping the version of Rust they require. Neither choice is great. The core team has discussed the idea of regular "long term support" releases, or otherwise some way to flag releases in a coarser-grained way. That can be useful for deprecations like this -- they would give something more like a small "epoch of Rust" to attach things like deprecations to, rather than forcing lib authors to just arbitrarily require Rust v1.7+ or whatever. More broadly, we'd like to establish a policy for this kind of minor cleanup -- where the change makes things more clear, but doesn't close any fundamental holes or anything. |
|
This is a very valid concern. Has a more fine-grained |
|
@SimonSapin yes, that idea has come up from time to time, and would definitely be helpful here. The main drawback is that it loses some of the point of deprecation -- if it's easy to opt out of the deprecation, there's little incentive to actually improve your code. Of course, in this particular case the use of deprecation is more about discoverability/documentation/API clarity than improving existing code per se. |
|
Other random idea: add the new name and deprecate the new one in a way that’s visible in the documentation but doesn’t emit a warning yet. (At least until the new name hits the stable channel.) |
|
@SimonSapin Yes, that's a feature we absolutely want -- basically, the ability to say "deprecated since Rust 1.8" or some other future release, and have the compiler/rustdoc do the right things. I'll open an issue for it. |
|
cc #30785 |
|
A possible alternative to |
|
Oh, and another idea we've talked about: the ability to |
The doc part of rust-lang#30459
|
Removing docs since my PR is in, now just a libs question if we want new versions. |
Fixes rust-lang#30459 Fun fact: i wanted to write "Arabic" and "Hebrew" in Arabic and Hebrew, but vim kept doing the copy/paste in the wrong direction.
Fixes rust-lang#30459 Fun fact: i wanted to write "Arabic" and "Hebrew" in Arabic and Hebrew, but vim kept doing the copy/paste in the wrong direction.
|
I believe #31202 closed this accidentally. At least, I can't see any documented decision from the libs team. |
Mark-Simulacrum
added
the
C-enhancement
…isdreavus,GuillaumeGomez Handle future deprecation annotations This adds special handling to the `since` parameter of the `deprecated` attribute: in particular, if the `since` version exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version. (I've used `since` for this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)   This is a prerequisite for doing things renaming methods in the standard library (e.g. rust-lang#30459). Resolves rust-lang#30785.
…isdreavus,GuillaumeGomez Handle future deprecation annotations This adds special handling to the `since` parameter of the `deprecated` attribute: in particular, if the `since` version exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version. (I've used `since` for this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)   This is a prerequisite for doing things renaming methods in the standard library (e.g. rust-lang#30459). Resolves rust-lang#30785.
|
Now that #30785 is merged, it would be feasible to add unstable cc @rust-lang/libs |
…petrochenkov Support future deprecation for rustc_deprecated Follow-up to #49179 to allow `since` parameters to be set to future versions of Rust and correspondingly to not be treated as deprecated until that version. This is required for #30459 to be completed (though we'll need to wait until this hits beta).
Add trim_start, trim_end etc.; deprecate trim_left, trim_right, etc. in future Adds the methods: `trim_start`, `trim_end`, `trim_start_matches` and `trim_end_matches`. Deprecates `trim_left`, `trim_right`, `trim_left_matches` and `trim_right_matches` starting from Rust 1.33.0, three versions from when they'll initially be marked as being deprecated, using the future deprecation from #30785 and #51681. Fixes #30459.
Rename to trim_start and trim_end for consistency with String, and in the spirit of their rename (not assuming RTL): rust-lang/rust#30459
…:rfind`. In the documentation comment for `std::str::rfind`, say "last" instead of "rightmost" to describe the match that `rfind` finds. This follows the spirit of rust-lang#30459, for which `trim_left` and `trim_right` were replaced by `trim_start` and `trim_end` to be more clear about how they work on text which is displayed right-to-left.
…r=thomcc Say "last" instead of "rightmost" in the documentation for `std::str:rfind` In the documentation comment for `std::str::rfind`, say "last" instead of "rightmost" to describe the match that `rfind` finds. This follows the spirit of rust-lang#30459, for which `trim_left` and `trim_right` were replaced by `trim_start` and `trim_end` to be more clear about how they work on text which is displayed right-to-left.
These functions and their
_matchesvariants operate on the start and end of the string, which are only the left and right (respectively) of the displayed text when rendered left-to-right like English. For (readers/users of) RTL languages,trim_rightis hinting that it will be trimming the prefix, but this is of course not the case (and similarly for_left).These are stable and there is precedent in other languages for left/right e.g. Python (there's also significant precedent for start/end), so we may not be able/want to do anything here, but it seems worth noting.
The text was updated successfully, but these errors were encountered: