Closed ole closed 7 years ago
@airspeedswift This one is probably for you?
cc @milseman
Yeah the compiler is still using the old grapheme breaking implementation. Workaround is to write
"\u{1F64D}\u{1F3FD}".first!
There's no good answer here. The compiler could use the same ICU-based grapheme breaking, but then code could fail to compile on machines with an older copy of the library that has different breaking. We could trap at runtime instead for 2+ character literals, or just silently ignore multi-character characters (either dropping the excess parts or letting characters essentially be strings). Probably best option is to warn instead of error in this case.
Oh yes, I hadn't considered the split between compiler and ICU. That makes sense. Thanks for the explanation.
Yes, this is the same as https://bugs.swift.org/browse/SR-4546
Environment
Apple Swift version 4.0 (swiftlang-900.0.49.1 clang-900.0.29) (Xcode 9 beta 3).Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Standard Library | |Labels | Bug | |Assignee | None | |Priority | Medium | md5: bc2370cb250cd6672de7818c125debc8duplicates:
Issue Description:
Tested on Xcode 9 beta 3.
Creating a
Character
from a grapheme cluster literal fails when the literal contains a complex emoji, e.g. one with a skin tone. I tested this with:(WOMAN + skin tone modifier). Creating the value with:
works fine.
It's not just skin tones. The same error occurs when the emoji is a profession without a skin tone, e.g.:
(MALE PILOT) also fails with the same error.