[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Alex Blewitt]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161020/074a2205/attachment.html>