On Wed, Oct 19, 2016 at 4:09 AM, Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote:
> Some extremely short-sighted points about deleting my formal operators > that are widely recognized as operators, and that I’ve spent months adding > into my code. Frankly, I just couldn’t upgrade until you put them back in. > Benjamin: The situation "behind the scenes" is that I've been working with Mark Davis to add Unicode standard properties for operator start and operator continue character sets in Unicode UAX31. That's a process whose scope needs to be broader than just Swift, and it's something that Swift will want to be compatible with. I think the intention would be to adopt that new part of UAX31 as soon as practical, and I am hopeful that specification will meet your needs and objectives. If not, I'd very much like to pick up that conversation with you offline to see how we can improve matters in UAX31. The UAX31 discussion seems to be converging rapidly. The proposal here is to *temporarily* limit operator identifiers to the ASCII operator characters. This is mainly intended to provide a bridge solution until UAX31 changes can be published in draft form. One reason to take a temporary step back is to ensure that we do not unintentionally specify something now that will become incompatible as soon as the UAX31 draft emerges. Changes to the operator identifier space are well-localized in the compiler implementation, and don't have any large-scale impact on later passes. They are one of the few kinds of compiler changes that can safely be made late in a development cycle. If this part of UAX31 converges as quickly as I expect, I think we can get that result reflected into Swift 4, and we can get a draft version implemented sooner. Jonathan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution