String Essentials

[Michael_Ilseman]

@nuclearace

Yes, these are some much needed things. Are there any immediate concerns with tackling this now? It doesn't seem like anything should be holding these additions up short of an implementation and proposal.

We should be able to develop the simple collection-taking findRange at any time. We’ll want to do a Pattern approach in the future and that could check for a trivial pattern and forwards on to the simple collection-taking findRange.

@nuclearace

I think the best way to solve most of these problems is just to go with Joe's suggestion and use a method for these kinds of operations. A substring method built on some kind of particularly powerful Collection.slice method side steps a lot of the concerns I think most people have with a subscript based solution.

The also sounds good to me, unless we can figure out the DSL approach soon. I do think we will want this on UnicodeScalarView and probably the code unit views.

@Joe_Groff

I think that, if the syntactic and design issues could be solved, this would be the ideal solution.

I agree, and I’m actually fine with Dave’s syntax (though I expect that to be highly controversial). Your thoughts on the syntax?

@Joe_Groff

It would be great to refine the RangeExpression protocol into something that can also abstractly express more complex relative index computations. That would give us something that works for all collections, as you noted, but also something that could work across collection operations, not just subscripting, since other range operations like replaceSubrange could use the same protocol to gain the same expressivity.

Interesting. Could you elaborate more on what you’d want to be able to express and how RangeExpression cannot meet that? Maybe instead of a slicing DSL we have a range DSL.

@fswarbrick

I have what I consider to be a decent implementation for trim/trimming. It's on BidirectionalCollection and then specialized as necessary for StringProtocol, String and Array. I'd be happy for it to be used as the base for a stdlib implementation.

I think the pressing need would be for the whitespace special case for [Sub]String (likely based on Character.isWhitespace assuming it reconciles degenerate graphemes), UnicodeScalarView (using Unicode.Scalar.Properties.isWhitespace), and maybe code unit views (if useful) as aliases for the USV solution.

Beyond that, let’s see if a Pattern abstraction covers all the others well.

For the mutating trim operation, I wonder if it would be best on RangeReplaceableCollection, which can delete prefixes or suffixes in-place.