The "Symbol, Other" category contains "Sign of the Horns" 🤘 which was one of the problems with the identifier/operator that kicked off these discussions.
http://www.fileformat.info/info/unicode/char/1f918/index.htm So it would break some existing cases, e.g.: 1> let \U+1F913 = "nerd face" 🤓: String = "nerd face" http://www.fileformat.info/info/unicode/char/1f913/index.htm On the other hand, there are some symbols in [:So:] that may be useful e.g. the APL Functional Symbol * series It might be easier to have just [:Sm:] to start with, and review the [:So:] subsequently (or have those addressed in UAX31). Alex > On 20 Oct 2016, at 15:29, Jonathan S. Shapiro via swift-evolution > <swift-evolution@swift.org> wrote: > > Quick poll as a sanity check on a possible alternative for operators: > > If we admitted [:Sm:] and [:So:] and the traditional ASCII operator > characters, would that cover the things that people currently feel passionate > about? That would almost certainly be compliant with UAX31 once it settles, > and I think it covers all of the cases people have raised here. > > Useful links if you want to check: > > [:Sm:] Symbol, Math > <http://www.fileformat.info/info/unicode/category/Sm/list.htm> > [:So:] Symbol, Other > <http://www.fileformat.info/info/unicode/category/So/list.htm> > > Having looked it over, I'm concerned about including [:Sk:] in UAX31 > operators, and I'm probably going to recommend in the UAX31 discussion that > we shouldn't do so. > > > Jonathan > _______________________________________________ > 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
