ASCII white space (in any encoding) by default with an optional user defined set of trim characters (like Python) would probably solve the needs of 90% of people rolling their own.

Not all unicode whitespace characters take up exactly one byte when encoded in utf8. Not even talking about other possible encodings, just good old utf8. Let that sink in a bit, and you'll realize what a can of worms it is in a language where strings are just byte sequences.

Because it's tricky is exactly why it should be in the standard library.

The C++ standard library should just incorporate ICU by reference IMHO.

ICU is an unreasonably large dependency for something that many users won't need. Its behavior also changes with new Unicode versions which makes it incompatible with something that cares as much as backward compatibility as the C++ standard library.

That’s the nature of Unicode: it’s complicated and a moving target.

As far as it being a large dependency, the beauty of C++ is that if you don’t use it, it won’t affect your build.

If ICU is too large, complex, and unstable for the C++ committee, then regular users don’t stand a chance.

> As far as it being a large dependency, the beauty of C++ is that if you don’t use it, it won’t affect your build.

That's the theory. In practice, you have things like iostreams pulling in tons of locale machinery (which is really significant for static builds) even if you never use a locale other than "C". That locale machinery will include gigantic functions for formatting monetary amounts even if you never do any formatting.

> If ICU is too large, complex, and unstable for the C++ committee, then regular users don’t stand a chance.

Regular users have more specific requirements and can handle binary compatibility breaks better if those aren't coupled with other unrelated functionality.

I mean, you're a big grown-up language with generic programming, why can't you:

https://doc.rust-lang.org/std/primitive.str.html#method.trim...

C++ can't manage to do this because it doesn't give its primitive types methods, it doesn't have a sensible way to talk about methods on types, and it always coerces to function pointers...

    assert_eq!("123foo1bar123".trim_end_matches(char::is_numeric), "123foo1bar");

But it's pretty easy to at least do this:

    assert_eq!("11foo1bar11".trim_end_matches('1'), "11foo1bar");

(Yes Rust does provide one that always trims off trailing whitespace, but that requires that you know, as Rust does, what the encoding is)