[SR-6077] `Character` ends up accepting invalid emoji flag sequences.

[YOCKOW]

Previous ID	SR-6077
Radar	None
Original Reporter	@YOCKOW
Type	Bug
Status	Resolved
Resolution	Won't Do

Environment

• Swift 4.0

• OS: macOS, Ubuntu 16.04

Additional Detail from JIRA

Votes	0
Component/s	Standard Library
Labels	Bug
Assignee	None
Priority	Medium

md5: c82e0168fd3a0f487ee734ba7518dfc4

relates to:

• SR-9206 Should literal Characters precondition on single-grapheme check?

Issue Description:

The Swift code below will be compiled without any errors, although it does not conform to Unicode segmentation algorithm.

let a: Character = "\u{1F1E6}" // REGIONAL INDICATOR SYMBOL LETTER A
let abc: Character = "\u{1F1E6}\u{1F1E7}\u{1F1E8}" //REGIONAL INDICATOR SYMBOL LETTER A-C

Expected Result
An error is raised such as error: cannot convert value of type 'String' to specified type 'Character'.

References

• UAX #29
  > Do not break within emoji flag sequences. That is, do not break between regional indicator (RI) symbols if there is an odd number of RI characters before the break point.
  > GB12 sot (RI RI)* RI × RI
  > GB13 RI (RI RI)* RI × RI

• UTS #51
  > emoji flag sequence — A sequence of two Regional Indicator characters, where the corresponding ASCII characters are valid region sequences
  > A singleton Regional Indicator character is called an ill-formed emoji flag sequence.

[belkadan]

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

[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).

[YOCKOW]

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.

[lorentey]

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.

[lorentey]

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