Add some of [T]’s methods to strings and vice versa

[ftxqxd]

Add some methods that already exist on slices to strings and vice versa. Specifically, the following methods should be added:

• str::chunks
• str::windows
• str::into_string
• String::into_boxed_slice
• <[T]>::subslice_offset

Rendered

[Kimundi]

Is the reason for adding <[T]>::subslice_offset just symmetry? I'm asking because I'm not sure if that function is actually used by anyone.

[ftxqxd]

@Kimundi I’ve wanted to use it in the past, but yeah, it’s mainly just to match the str API. I wouldn’t really care if subslice_offset got removed from str (it’s not very useful), but I’d certainly prefer to either have it for both types or neither, rather than just one.

[Gankra]

Is there really a usecase for str::chunks or windows?

[gkoz]

Out of curiosity, what is Box<str> for? I haven't encountered any mentions of this type before.

[Gankra]

@gkoz In principle it's just a runtime-constructed &'static str (string litteral). one usize thinner than a String, but effectively immutable as a result.

[ftxqxd]

@gankro str::windows could be used to calculate the Sørensen–Dice coefficient of two strings, and str::chunks has been asked for on IRC a few times.

[huonw]

Hm, I suspect windows and chunks will encourage bad Unicode practice without a huge amount of benefit other than symmetry. Specifically they will split between combining characters.

[SimonSapin]

“Character” is kinda ambiguous. (Unicode has four different definitions.) Maybe use chars instead?

[krdln]

+1 to functions involving Box<str>. I was surprised they weren't implemented. And it's good to lose those 4/8 bytes sometimes (especially when within an enum).

-1 to windows and chunks. I second @huonw that they encourage bad practices. I think they belong in unicode crate with codepoint_ and grapheme_ variants.

[krdln]

I just stumbled upon the lack of str::shift_char() counterpart for a slice. I guess it would also be worth adding.

[ftxqxd]

I just stumbled upon the lack of str::shift_char() counterpart for a slice. I guess it would also be worth adding.

@krdln #1058 already adds that, I believe.

[comex]

May be out of scope, but I'd like to see some form of find, rfind, replace, and other pattern-based methods added to [T] or Vec<T>. This would be useful, for example, when dealing with a &[u8] which represents a "string" that may not be valid UTF-8 (such as the contents of a Unix OsStr) - or just random binary data, for that matter.

[Gankra]

I concur with @huonw on the dubiousness of windows and chunks in the face of combining characters. It's not clear to me how the Sørensen–Dice coefficient is even supposed to interact with utf8 in that regard.

👍 on the Box conversions. Makes sense.

I'm completely indifferent on subslice_offset

[alexcrichton]

This RFC is now entering its final comment period.

[alexcrichton]

I would personally prefer to not add this method to slices just yet, I suspect it won't survive stabilization of strings.

[alexcrichton]

I also agree with @huonw about being hesitant to add windows/chunks to strings due to unicode fun stuff.

[nagisa]

https://github.com/rust-lang/rfcs/pull/1152/files#r32605082 ditto.

[sfackler]

The Box<str> methods seem good to me but I share the unicode weirdness concerns above with respect to chunks and windows and am not sold on the utility of subslice_offset.

[Gankra]

@P1start the libs team seems pretty unanimous about Box<str> is great, everything else is not. Is this an acceptable result of this RFC, for you?

[ftxqxd]

@gankro Yep, that’s fine by me. I’ll update the RFC soon to include just those methods (and rename into_boxed_slice to into_boxed_str unless anyone has any objections).

[ftxqxd]

RFC updated, removing str::windows, str::chunks, and <[T]>::subslice_offset.

[alexcrichton]

The consensus of the libs team is to merge this RFC, so I will do so. Thanks again @P1start!

[aturon]

Tracking issue.