String hygiene

[Michael_Ilseman]

@Erica_Sadun

I don't mind returning an empty substring but what is the best way to construct that?

How about ""[...], or String()[...]?

@Erica_Sadun

Still up for grabs:

• grapheme-by-grapheme or scalar-by-scalar (I want accented whitespace to be non-whitespace)
• What types/protocols adopt this: string, substring, stringprotocol, unicodescalarview
• A standards based decision of what constitutes whitespace, coordinated with character properties and other proposals.

I started Corner-cases in `Character` classification of whitespace. Could you elaborate there why you don't want "\u{020}\u{301}" to be whitespace?

I think this should clearly be on StringProtocol (and thus String and Substring). If we go with the non-scalar interpretations of whitespace, then we should definitely have it on all 3 (sigh) UnicodeScalarViews in the stdlib.

@kiel

I feel strongly about allowing the caller specify the Set<Character> value because it'd be a regression over NSString 's trimmingCharacters(in:) API, API which provides an expectation or precedent for expected behaviour. Failing to match its functionality in this case would increase residual dependence on Foundation and limit the portability of a codebase to other platforms.

Another reason I feel strongly about it is there are times when I've wanted to strip some whitespace to the exclusion of others. More relevant to the present discussion is what counts as whitespace, changes to that definition in the future and perhaps trivially, any concerns about performance and the number of members in the character set.

Also, in my opinion, there's nothing more infuriating than an API lacking simple affordances.

I think having an overload that takes a Set<Character> would be very useful. The overload that doesn't take such a set could still be implemented more efficiently.

Should we have such trimmed overloads on BidirectionalCollection? Should we have one that takes a Set<Element> and/or one that takes (Element) -> Bool? This could be pretty simple, implemented in terms of drop(while:) from the front and an equivalent (to be pitched, I suppose) drop-while from the back.

This way we can trim e.g. Arrays in general. It would also provide a better interim story for users who are stuck using [UInt8] instead of String.

@sbromberger

Understood, but do the meanings of "start" and "end" change based on the directionality of the language? It seems to me that "right" and "left" don't. (Even though I think "start" and "end" are more intuitive for LTR languages.)

"start" and "end" already carry connotations, e.g. startIndex and endIndex. Trimming is similar to chaining str.dropFirst(...).dropLast(...), so I suppose "first" and "last" are also up for grabs. Finally, "leading" and "trailing" may also be good names. Directionality doesn't affect sequence order of the graphemes themselves. It applies more so to rendering, presentation, and other interpretation.