I'm well aware that surrogates are only valid in the context of UTF-16's encoding. > If you're adding them into your program by hand on purpose, you're either

I'm well aware that surrogates are only valid in the context of UTF-16's encoding. > If you're adding them into your program by hand on purpose, you're either doing it wrong or specifically to raise an error for illustration purposes. In the comments above, it should be obvious that it is for illustrative purposes. The point is that the string type does not catch these errors. It's not that someone is going to "add them to the program … on purpose" … it's that they're going to slip in from bad data, or bad code, not on purpose but because people write bugs and generate garbage data. A good type does not let you represent illegal states. For the same reason null is a bad idea — here, it's not a valid unicode string. The point of a Unicode string type would be to expose operations that one might want to perform on Unicode strings. By permitting invalid values to exist in the set of values the type can represent, you're basically making every operation fallible or GIGO. For example, take a function that would iterate over the string and yield the USVs within it — a borderline trivial operation, but basically a fundamental building block of any higher Unicode function we might want — it cannot process the example string from my previous comment without either raising, or yielding garbage/invalid USVs. Make illegal values actually illegal, and "iterate over the USVs" becomes an infallible method. This is no different than a bool that permits representing a "2", where a "2" has no well-defined meaning. You're just breeding bugs, at that point.