Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-5448] Creating a Character via ExpressibleByExtendedGraphemeClusterLiteral fails with complex emoji #48020

Closed
ole opened this issue Jul 12, 2017 · 4 comments
Closed

[SR-5448] Creating a Character via ExpressibleByExtendedGraphemeClusterLiteral fails with complex emoji #48020

ole opened this issue Jul 12, 2017 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@ole
Copy link
Contributor

ole commented Jul 12, 2017

Previous ID SR-5448
Radar None
Original Reporter @ole
Type Bug
Status Resolved
Resolution Duplicate
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: bc2370cb250cd6672de7818c125debc8

duplicates:

  • SR-4546 Need more permissive ExtendedGraphemeClusterLiteral parsing

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:

"\u{1F64D}\u{1F3FD}"

(WOMAN + skin tone modifier). Creating the value with:

Character("\u{1F64D}\u{1F3FD}")

works fine.

> xcrun swift
Welcome to Apple Swift version 4.0 (swiftlang-900.0.49.1 clang-900.0.29). Type :help for assistance.
  1> let c: Character = "\u{1F64D}" // woman
c: Character = {
  _representation = smallUTF16 {
    smallUTF16 = 3729643581
  }
}
  2> let d: Character = "\u{1F64D}\u{1F3FD}" // woman + skin tone
error: repl.swift:2:20: error: cannot convert value of type 'String' to specified type 'Character'
let d: Character = "\u{1F64D}\u{1F3FD}" // woman + skin tone
                   ^~~~~~~~~~~~~~~~~~~~


  2> let e = Character("\u{1F64D}\u{1F3FD}") // woman + skin tone
e: Character = {
  _representation = large {
    large = {
      _nativeBuffer = 0x8000000100205330
    }
  }
}

It's not just skin tones. The same error occurs when the emoji is a profession without a skin tone, e.g.:

let f: Character = "\u{1F468}\u{200D}\u{2708}\u{FE0F}"

(MALE PILOT) also fails with the same error.
@ole
Copy link
Contributor Author

ole commented Jul 12, 2017

@airspeedswift This one is probably for you?

@airspeedswift
Copy link
Member

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.

@ole
Copy link
Contributor Author

ole commented Jul 12, 2017

Oh yes, I hadn't considered the split between compiler and ICU. That makes sense. Thanks for the explanation.

@milseman
Copy link
Mannequin

milseman mannequin commented Jul 12, 2017

Yes, this is the same as https://bugs.swift.org/browse/SR-4546

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ole @airspeedswift