See rust-lang/rust#26499 (related discussion)

Thanks. I'd missed that discussion.

starts_with and ends_with (and contains) could certainly be implemented for general OsStr arguments, although I don't think the straight byte comparison proposed there handles WTF-8 unpaired surrogates correctly.

That also suggests the question of whether these functions should take things like &str or things like T: AsRef<str>. I see std interfaces going both ways. Which is preferred for new interfaces?

Thanks for the RFC @wthrowe! It does seem high time that we start expanding the API for OsStr, so thanks for pushing on it!

My thoughts on this in the past have been primarily along the lines of:

• All extensions should mirror str in one form or another wherever possible
• Questions about encoding and such tend to work best if we can somehow sidestep the entire question (depends on the question at hand)
• The encoding question may end up meaning that some str APIs aren't quite appropriate for OS strings, but it's certainly a space to explore!

I'll look into writing up equivalents of some of the more general pattern matching str methods and replacing things those make obsolete. The only difficulty I can think of immediately is figuring out what patterns that match the empty string should do.

Yeah I agree that str.split("") has a pretty good meaning whereas os_str.split("") may not. This may not be able to go the route of a "full Pattern trait" just yet which is totally fine, just food for thought!

New version, now with more patterns!

The previous proposed functions have mostly been replaced with a new interface matching str as closely as possible, but with a few new OsStr-specific operations.

I did decide to not propose slice_shift_char in the end, as I think I'd prefer to go the route of proposing more general functions for both str and OsStr, probably along the lines of fn split_prefix<P: Pattern<'a>>(&'a self, pat: P) -> Option<(&'a str, &'a Self)>, kind of like the current str::split_at. (slice_shift_char is then split_prefix(|_| true), except for some minor type differences.) (The idea that this would also be nice for str was pointed out by @SimonSapin in some line comments above.) It does make this proposal less useful in isolation, but I think it's a better direction in the long run.

The main uncertainty in the new version is what to do with patterns that match the empty string. The non-iterator functions (like contains) have pretty obvious interpretations, but the iterator ones (like matches) don't. I've listed a few possibilities in the text, but I think some more discussion is needed on this.

One more thought on patterns: With more complicated implementors of Pattern (like regular expressions or something) the concept of "matches the empty string" is not even terribly meaningful. A pattern might match some empty strings but not others, depending on context. The most reasonable idea might be to just declare that patterns are matched against each Unicode section separately. (And maybe at the beginning and end of the string in any case, since it would feel odd for .starts_with("") to ever give false.)

I've unfortunately not been able to find much time to allocate to this RFC, so @Kimundi (who originally developed the pattern API for strings) is gonna take over this.

Hi, just wanted to say that haven't forgotten about this RFC, but I'm currently investigating how a fully general pattern API (for arbitrary slice types) would look like, and whether there might be incompatibilities or method name clashes with this RFC.

@Kimundi Thanks for the update - could really do with this functionality!

Update:

I have a incomplete, undocumented prototype at https://github.com/Kimundi/rust_pattern_api_v2 that provides the same Pattern API + iterators for both & and &mut of str, [T], and OsStr.

I need to find time to do a proper writeup for my findings, but in regard to this RFC the cliff notes are:

• There are two separate Pattern API's for OsStr:
  • one for searching sub-str slices which is identical to the str API: Patterns str, char, char predicates.
  • one for searching sub-OsStr slices with Patterns OsStr, str, char, char predicates.
    • searching for OsStr patterns has the edge case of needing to reject patterns on windows that start/end with the wrong kind of leading/trailing surrogate, since the Pattern API would not always be able to return slices to the haystack string that contains them. The alternative to a panic/err result would be to make the Pattern impl return Cow<OsStr> values.
• If both are provided in some capacity, like in this RFC, they should probably be provided consistently and uniformly.
  • Eg. there should for example be symmetrical sets of Pattern-using foo and foo_os methods like contains() and contains_os(), instead of the proposed mix of, eg, contains() that works similar to taking a OsStr Pattern vs starts_with() taking a str Pattern.
• The "unicode embedded in OsStr" behavior seems to be implementable without going through the split_unicode layer and requiring cloneable Patterns.

The libs team discussed this RFC recently and the conclusion was that while we'd like to implement something along these lines the RFC will need much of a revamp now and we unfortunately haven't been able to reach the author, so we're going to close. We're of course quite willing to entertain RFCs in this area though!