> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution > <swift-evolution@swift.org> wrote: > > Hi All. > > I’d like to help as well. I have fun with operators. > > There is also the issue of code security with invisible unicode characters > and characters that look exactly alike.
Unless there is a compelling reason to add them, I think we should ban invisible characters. What is the harm of characters that look alike? -Chris > (They should make a Coding font that ensures all characters look different.) > Was that ever resolved? Googling, I found this: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021446.html > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021446.html> > > Which seems to have been left at this: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025555.html > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025555.html> > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/thread.html#27229 > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/thread.html#27229> > > Should we throw all of this into the same pot, and make any characters that > aren’t on the approved list illegal? > > -Kenny > > >> On Sep 30, 2017, at 4:13 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I’m happy to participate in the reshaping of the proposal. It would be nice >> to gather a group of people again to help drive it forward. >> >> That said, it’s unclear to me that superscript T is clearly an operator, any >> more than would be superscript H (Hermitian), superscript 2, superscript 3, >> etc. But at any rate, this would be discussion for the future workgroup. >> >> I would strongly advocate that the things-that-are-identifiers group be >> strongly tied to the existing, complete Unicode standard for such, and that >> the critical parts of the previous document about normalization be retained. >> >> On Sat, Sep 30, 2017 at 17:59 Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> The core team recently met to discuss PR609 - Refining identifier and >> operator symbology: >> https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/NNNN-refining-identifier-and-operator-symbology.md >> >> <https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/NNNN-refining-identifier-and-operator-symbology.md> >> >> The proposal correctly observes that the partitioning of unicode codepoints >> into identifiers and operators is a mess in some cases. It really is an >> outright bug for 🙂 to be an identifier, but ☹️ to be an operator. That >> said, the proposal itself is complicated and is defined in terms of a bunch >> of unicode classes that may evolve in the “wrong way for Swift” in the >> future. >> >> The core team would really like to get this sorted out for Swift 5, and >> sooner is better than later :-). Because it seems that this is a really >> hard problem and that perfection is becoming the enemy of good >> <https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good>, the core team >> requests the creation of a new proposal with a different approach. The >> general observation is that there are three kinds of characters: things that >> are obviously identifiers, things that are obviously math operators, and >> things that are non-obvious. Things that are non-obvious can be made into >> invalid code points, and legislated later in follow-up proposals if/when >> someone cares to argue for them. >> >> >> To make progress on this, we suggest a few separable steps: >> >> First, please split out the changes to the ASCII characters (e.g. . and \ >> operator parsing rules) to its own (small) proposal, since it is unrelated >> to the unicode changes, and can make progress on that proposal independently. >> >> >> Second, someone should take a look at the concrete set of unicode >> identifiers that are accepted by Swift 4 and write a new proposal that >> splits them into the three groups: those that are clearly identifiers (which >> become identifiers), those that are clearly operators (which become >> operators), and those that are unclear or don’t matter (these become invalid >> code points). >> >> I suggest that the criteria be based on utility for Swift code, not on the >> underlying unicode classification. For example, the discussion thread for >> PR609 mentions that the T character in “ xᵀ ” is defined in unicode as a >> latin “letter”. Despite that, its use is Swift would clearly be as a >> postfix operator, so we should classify it as an operator. >> >> Other suggestions: >> - Math symbols are operators excepting those primarily used as identifiers >> like “alpha”. If there are any characters that are used for both, this >> proposal should make them invalid. >> - While there may be useful ranges for some identifiers (e.g. to handle >> european accented characters), the Emoji range should probably have each >> codepoint independently judged, and currently unassigned codepoints should >> not get a meaning defined for them. >> - Unicode “faces”, “people”, “animals” etc are all identifiers. >> - In order to reduce the scope of the proposal, it is a safe default to >> exclude characters that are unlikely to be used by Swift code today, >> including Braille, weird currency symbols, or any set of characters that are >> so broken and useless in Swift 4 that it isn’t worth worrying about. >> - The proposal is likely to turn a large number of code points into >> rejected characters. In the discussions, some people will be tempted to >> argue endlessly about individual rejections. To control that, we can >> require that people point out an example where the character is already in >> use, or where it has a clear application to a domain that is known today: >> the discussion needs to be grounded and practical, not theoretical. >> >> >> Third, if there is interest sometime in the future, we can have subsequent >> proposals that expand the range of accepted code points, motivated by the >> specific application domain that cares about them. These proposals will not >> be source breaking, so they can happen at any time. >> >> >> Is anyone interested in helping to push this effort forward? >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
