There is no type that provides a guarantee of having only one grapheme inside.

[Hedgehogo]

This type could be an Iterator::Item for Graphemes, and could also have specific methods similar to those of char, such as is_ascii. Replacing Iterator::Item now required breaking backwards compatibility. However, the very introduction of this type, even without replacement, would have been useful. As it would have become a single standard for such a guarantee and many traits of unrelated crates would have been implemented for it.

Suggested title: `Grapheme'.

[Manishearth]

For what reason would such a type be useful?

This guarantee doesn't hold across Unicode versions, so it's a bit tenuous.

[Hedgehogo]

This guarantee doesn't hold across Unicode versions, so it's a bit tenuous.

This is not a Unicode guarantee, it is a guarantee of your iterator, its description says that it iterates over graphemes, hence Item in this iterator is a grapheme, regardless of whether it can be broken into more graphemes.

&str in the general case contains an unlimited number of graphemes, in particular 0. And the proposed type will give a guarantee that its contents can be treated as exactly one grapheme. This allows us to add at least a function that returns the first codepoint, because a grapheme cannot consist of zero codepoints. This allows us to add functions is_whitespace or is_emoji which cannot be defined for &str in the general case, because each grapheme in a string may or may not individually satisfy these conditions. The only functions that can be defined for &str are is_all_whitespace or is_any_whitespace, and a large zoo of other functions, which obviously indicate the lack of proper typing.

[Manishearth]

Yes, but which strings are graphemes changes with Unicode versions: a crate providing is_emoji() would have to keep its unicode versions in sync. If you're suggesting that this crate provide such a function, I think that's another expansion of scope; and I'd like to see the full surface area you are proposing because I'm reluctant to add too much to this crate.

I'd recommend crates which wish to provide such functionality define their own grapheme type and wrap it, and we can merge the impls in the future if folks really want to.