# String hygiene **URL:** \ **Category:** Discussion\ **Created:** [May 18, 2018, 11:06pm UTC](https://forums.swift.org/t/string-hygiene/12826 "2018-05-18T23:06:08Z")\ **Posts on this page:** 1\ **Showing post:** 50
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [May 22, 2018, 9:35pm UTC](https://forums.swift.org/t/string-hygiene/12826/50 "2018-05-22T21:35:26Z")
> [@Michael\_Ilseman](#): > > 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) `UnicodeScalarView` s in the stdlib. This particular effort was not started to create a perfect API. It is to respond to a community-sourced need that is not satisfied by the current standard library. That's why I've been wavering between producing a `Substring` and `String`. This is really the first effort to push into this community-driven space. As I review the original use-cases, they are meant to produce `String`s without coercion, and where efficiency is not a motivating factor. If we are driven by a particular use-case, how far should we go with that muse. Certainly we want something to be as useful as possible and as Swifty as possible but if we start returning Substrings, I can foresee many libraries implementing `var trimmedAsString` because we're _not giving people the tool that does what they want and need_. Producing a string isn't the most efficient approach nor is it the most general but it provides tooling that expresses the task common to an overwhelming number of use cases. In exploring this area, pulling on a single thread is proving to unravel a much bigger problem than we set out to solve. To recap: - Andrew discovered a great demand for `String.trim`. - We did not want this tooling to depend on Cocoa. - We wanted to add a simple way to offer start-or-end trimming. - We wanted to define what whitespace meant. - We wanted to define what a general trimming API would look like. Maybe the [What `Character`s are and are not whitespace?](https://forums.swift.org/t/what-character-s-are-and-are-not-whitespace/12900) discussion should be expanded to include all pertinent character sets. Perhaps some of that work has already been covered in [Character properties](https://github.com/milseman/swift-evolution/blob/60c7c82b1940c961044337d520dc0f9b298d982e/proposals/nnnn-character-properties.md). And maybe that's a can that can be kicked down the road as an implementation detail that can be changed without Swift Evolution discussion. `trimmingCharacters(in:)` is a part of `StringProtocol`. We may want to enhance that API to include `from:` for `.start` and `.end`. If `StringProtocol` offers `trimmingCharacters(in:, from: = default)`, this proposal becomes way simpler because it just has to call it with whatever the character set for newlines and whitespaces becomes. At the same time, `trimmingCharacters(in:)` returns `String`. Maybe it shouldn't. Also, strings aren't the only trimmable thing: so are arrays or really any bidirectionalcollection. Anyway, I don't want to lose sight of our brief: introduce a convenient way to trim a string. --- _[View the full topic](https://forums.swift.org/t/string-hygiene/12826)._