> On Feb 16, 2017, at 9:50 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised > proposal in draft form. > > It proposes a source-breaking change for rationalizing which characters are > permitted in identifiers and which in operators. It's justified for this > phase of Swift 4 because: > > - Existing grammar, in permitting invisible characters without > security-minded restrictions, can be actively harmful. > - A rationalized approach is superior to the current approach: by referencing > Unicode standards, Swift should be able to evolve in a backwards-compatible > way alongside Unicode, and will benefit from the significant expertise of > others outside the Swift community with respect to Unicode best practices. > - The vast majority of existing code (including all of the standard library) > should require no migration work at all > > What's changed since the last time: > > - In an earlier draft, we proposed some radical changes to align with > available Unicode standards; in particular, since emoji represent a difficult > issue, and no recommendations about "operator identifiers" have surfaced from > Unicode, we proposed temporarily stripping them out. This was very poorly > received. This revision uses Unicode categories to identify nearly all emoji > and classify them as identifier characters (while excluding those that depict > operators such as !), and it uses Unicode categories to identify over 900 > operators that nearly all pass the subjective test of "operator-likeness." > >
I was one of the people leading the charge for preserving Emoji support and I really like where this proposal landed. Thank you to all the authors for the hard work! +1 Russ
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
