str's trim_left and trim_right implicitly assume LTR text

[huonw]

These functions and their _matches variants 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_right is 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.

[sfackler]

I seem to recall Android adding start and end variants of some alignment constraints and deprecating the old left and right versions for this reason.

[SimonSapin]

+1 for start and end. CSS introduced the same keywords when generalizing text layout to RTL and vertical text. (And inline-start, inline-end, block-start, block-end when disambiguation is needed.)

How does the libs team feel about deprecating stable APIs?

[abonander]

Can confirm: left/right => start/end on Android. In XML the former pair is only linted against; I don't know if it's deprecated in the Java APIs. It's kind of annoying because I also use left/right for layout alignments that shouldn't change between LTR and RTL.

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.

[huonw]

Do we even have a way to detect an RTL configuration anyways?

No we don't.

Perhaps this is best left to an external crate to implement these methods as a precursor to a more general localization framework.

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 trim_right == start for RTL text, i.e. trim_left will always operate on the start and trim_right always on the end. Consistently trimming at the start/end no matter the direction of text seems likely to be the desired behaviour in most circumstances (i.e. even ones that encounter non-LTR text).

[SimonSapin]

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 str::trim_left and str::trim_right really mean lower memory addresses and higher memory addresses, so that naming is only correct when the text happens to be left-to-right. I’m proposing to add str::trim_start and str::trim_end with the same behavior, but more correct naming. And maybe deprecating the old names. Similarly with other methods with left and right in the name.

Methods with an r prefix (like rfind) have the same problem, but I don’t have a good replacement to suggest right now.

[abonander]

Okay, I see now. The text gets reversed during rendering--in memory the start of the string is at index 0 regardless of configuration. In that case I don't really have anything against the change itself.

As for the r prefix, I assumed it meant "reverse", which still makes sense in RTL. We can clarify that in documentation.

[SimonSapin]

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, rfind as "reverse find" rather than "find from the right" works.

[aturon]

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.

[SimonSapin]

This is a very valid concern. Has a more fine-grained #[allow(deprecated(some feature))] been considered?

[aturon]

@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.

[SimonSapin]

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.)