Trim/TrimStart/TrimEnd should allow optional nonwhitespace chars

bgrommes

Problem

Occasionally you want to remove not just whitespace, but other junk from strings. C# String.Trim() methods take an optional char array of characters to remove, which is handy when cleaning up "dirty" input.

Proposed Solution

Optional string argument consisting of 0 or more "characters" to also remove. Alternatively it could require the optional arg to consist of at least 1 character or to be omitted altogether.

Example Workflow

Print("  ***WHEE!***  ".Trim("*")). # "WHEE!"

Alternatives considered

In C# you have to include ALL the characters you want trimmed, and an empty char[] will cause it to default back to removing whitespace.

I think Trim() functions should ALWAYS remove whitespace and the other characters should be in addition. Partly because in the above example, requiring " *" (space plus asterisk) doesn't account for other whitespace including non-ASCII whitespace. I think the base functionality should handle all whitespace and the optional argument should be "extras".

More elaborate needs, such as removal of only certain non whitespace characters, can be accomplished via string extension methods. This leaves the Trim() function's original whitespace handling nature intact.

Garry

Thanks for the suggestion. I’ve added this for the next release: https://feedback.objo.dev/feature/734

String.Trim(), TrimStart(), and TrimEnd() now have overloads that accept a string containing the characters to remove:

Print("*#hello#*".Trim("*#"))          # "hello"
Print("***hello***".TrimStart("*"))    # "hello***"
Print("***hello***".TrimEnd("*"))      # "***hello"

The supplied string is treated as a set of individual characters, not as a complete prefix or suffix.

I decided that supplying characters should replace the normal whitespace behaviour rather than add to it. This means Trim("*") removes only asterisks and does not silently remove whitespace. The existing parameterless methods continue to remove Unicode whitespace as before.

For the example in the original post, include both the space and asterisk:

Print(" ***WHEE!*** ".Trim(" *"))    # "WHEE!"

Passing an empty string removes nothing:

Print("  hello  ".Trim(""))    # "  hello  "

The implementation also handles characters outside the Basic Multilingual Plane as complete Unicode code points.

bgrommes

Garry I can see an argument for either approach for how the optional argument works but to truly get the combined behavior (all whitespace plus specified characters) you would really need a constant with all the possible whitespace characters, e.g., Trim(_whitespaceChars + "*-") or whatever. OTOH in practice probably an ASCII space is sufficient for most situations, e.g., Trim(" *-").

I can generate a string full of whitespace characters in my budding framework as it has a lookup table of character types (which in turn I generated from a C# program based on Char.IsWhiteSpace(), etc) but if it were a constant like say System.WhitespaceChars As String that would be useful at times. Note that this would typically also include tabs, CR, LF, FF and the like, it isn't just a question of non-ASCII whitespace. I also make the distinction between all whitespace and non-breaking whitespace for when it matters, but for string trimming, the distinction wouldn't matter. It's more a thing involving goals like removing consecutive/duplicate whitespace when normalizing a string, etc.

Garry

That’s a fair point. There currently isn’t a concise way to request the union of Unicode whitespace and a supplied character set, and chaining the two Trim() overloads is not always equivalent because each pass can expose more characters for the other pass.

Rather than expose a fixed whitespace string that could drift from the Unicode definition used by the runtime, I think the cleaner future addition might be overloads such as Trim(characters, includeWhitespace), with equivalents for TrimStart() and TrimEnd(). That would allow value.Trim("*-", True) while keeping Trim("*-") precise and predictable.

What do you think?

bgrommes

Garry That seems like a good proposal to me. It allows more flexibility in how Trim() is used, while maintaining intentionality on the part of the developer. The only fly in the ointment is that Trim("",False) would create a do-nothing call scenario. That particular combination of runtime argument values should arguably be an error, but even there, I'd lean toward leaving it as a developer responsibility.