I suspect we're not going to do this simply because the Unicode standard changes and we wouldn't want existing code to stop compiling. This would have been invalid for a different reason in Unicode 9.

cc @airspeedswift

Right, we generally think the attempt to compile-time-validate graphemes previously to be a bit of a misadventure that leads to odd behavior when the compiler and OS differ. So we now only do it on a best-efforts basis (similar to how we catch some literal overflow issues but not others).

Thank you for your responses.
I was just concerned about the difference from the failure that let rnr: Character = "\r\n\r" could not be compiled.

let a: Character = "\u{1F1E6}"

This one is OK. "\u{1F1E6}" is a string of count 1. (Ill-formed emojis still have well-defined grapheme breaks around them.)

let abc: Character = "\u{1F1E6}\u{1F1E7}\u{1F1E8}"

This one is most definitely not okay. "\u{1F1E6}\u{1F1E7}\u{1F1E8}" is a string of count 2, so it cannot be considered a Character.

I suspect we're not going to do this simply because the Unicode standard changes and we wouldn't want existing code to stop compiling.

Character has the invariant that it must not contain a grapheme break. This invariant must not be violated.

Evidently there is currently no limit how many Characters a Character may contain.

let lovely: Character = "\u{1F1E6}\u{1F1E7}\u{1F1E8}\u{1F1E9}\u{1F1EA}\u{1F1E6}\u{1F1E7}\u{1F1E8}\u{1F1E9}\u{1F1EA}\u{1F1E6}\u{1F1E7}\u{1F1E8}\u{1F1E9}\u{1F1EA}\u{1F1E6}\u{1F1E7}\u{1F1E8}\u{1F1E9}\u{1F1EA}\u{1F1E6}\u{1F1E7}\u{1F1E8}\u{1F1E9}\u{1F1EA}"
print(String(lovely).count) // 13