Shane F. Carr

The current semantics of UnvalidatedStr are: - Serialization: bytes in binary, string or error in human-readable - Deserialization: bytes in binary, string in human-readable This is somewhat handy because it...

A name I've been using on my branch is `BytesOrStr` (could also be `StrOrBytes`). In that pattern, just prepend "BytesOr" or append "OrBytes" to the validated type name.

> `BytesOrStr` sounds like it's an enum and that having bytes is actually fine, when in fact it's an error/gigo case. This was a progression from my suggestion that it...

I still like SchrödingerStr modulo the issues with the namesake historical figure. Can't we come up with some other "clever" term a la elsa::FrozenMap, yoke::Yokeable, ... ?

Should we consider a name like PotentiallyIllFormedUtf8? Is there a semantic difference?

I am not very happy with that proposal because: 1. In the OP, I said I would prefer to avoid negated terms like `un` or `dis` or `non`. I prefer...

Bikeshed, with some help from gemini: - `RawStr` - `DeferredStr` - `QuasiStr` - `ChameleonStr` - `ProspectStr` - `OptimisticStr` - `PotentialStr` If we don't like any of those, how about choosing...

What did you all think of `PotentiallyIllFormedUtf8` "Potentially ill-formed UTF-8" is an established concept in the industry. Actually we already use it in `icu_segmenter`. The type name is a bit...

A potential advantage of this approach is that we could start having APIs such as ```rust pub fn process(s: &str) pub fn process_utf8(s: &PillStr) pub fn process_utf16(s: &PillUtf16) ```

The crate should also have an optional dependency on `writeable` as discussed in https://github.com/unicode-org/icu4x/pull/4786#discussion_r1559627673