On Sat, Oct 22, 2016 at 1:37 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution@swift.org> wrote:
> I just read through your new proposal, and I have to say it is extremely > well-written. There is a vast quantity of information presented quite > clearly, and it gives me a lot to think about. > > > On Fri, Oct 21, 2016 at 5:38 PM, Jonathan S. Shapiro <jonathan.s.shapiro@ > gmail.com> wrote: > >> On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via >> swift-evolution <swift-evolution@swift.org> wrote: >> >>> I think it is plainly evident that the well-defined criteria you would >>> like to use *have not yet been defined* by Unicode. That is a large part of >>> why I recommend that we postpone a major overhaul of our operator >>> characters. >>> >> >> That's a feasible way to go, but keep in mind that the UAX31 changes are >> being co-designed with and informed by the current discussion. There are a >> bunch of things that have come up here that will allow UAX31 to side-step >> some "might have happened" mistakes, so this discussion has been very >> useful. >> >> The Swift community can and should make its own decision about whether to >> remain engaged. The risk of disengagement is that messy compatibility >> issues will probably have to be faced later that we can easily head-off now. >> > > Ah, I had not previously understood that. Well then, in light of the fact > that the Unicode recommendations may be influenced by our decisions, and > given that Swift is an opinionated language, it follows that we ought to > make our best effort at separating out what we have been calling “operator > characters” (and your revised proposal calls “symbol identifier” > characters). > > In particular, since there does not yet exist a categorization of symbols > which fits our needs, and since our needs may help shape such a > categorization as it forms, it behooves us to fully undertake the endeavor > of defining which symbols we would like to see in which roles for Swift. > > Your proposal mentions and links to a set of 650 code points > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%21%5C%24%25%5C%26*%2B%5C-%2F%3C%3D%3E%3F%5C%5E%7C%7E%0D%0A%0D%0A%5Cu00AC%0D%0A%5Cu00B1%0D%0A%5Cu00B7%0D%0A%5Cu00D7%0D%0A%5Cu00F7%0D%0A%0D%0A%5Cu2208-%5Cu220D%0D%0A%5Cu220F-%5Cu2211%0D%0A%5Cu22C0-%5Cu22C3%0D%0A%5Cu2212-%5Cu221D%0D%0A%5Cu2238%0D%0A%5Cu223A%0D%0A%5Cu2240%0D%0A%5Cu228C-%5Cu228E%0D%0A%5Cu2293-%5Cu22A3%0D%0A%5Cu22BA-%5Cu22BD%0D%0A%5Cu22C4-%5Cu22C7%0D%0A%5Cu22C9-%5Cu22CC%0D%0A%5Cu22D2-%5Cu22D3%0D%0A%5Cu2223-%5Cu222A%0D%0A%5Cu2236-%5Cu2237%0D%0A%5Cu2239%0D%0A%5Cu223B-%5Cu223E%0D%0A%5Cu2241-%5Cu228B%0D%0A%5Cu228F-%5Cu2292%0D%0A%5Cu22A6-%5Cu22B9%0D%0A%5Cu22C8%0D%0A%5Cu22CD%0D%0A%5Cu22D0-%5Cu22D1%0D%0A%5Cu22D4-%5Cu22FF%0D%0A%5Cu22CE-%5Cu22CF%0D%0A%0D%0A%5Cu2A00-%5Cu2AFF%0D%0A%0D%0A%5Cu27C2%0D%0A%5Cu27C3%0D%0A%5Cu27C4%0D%0A%5Cu27C7%0D%0A%5Cu27C8%0D%0A%5Cu27C9%0D%0A%5Cu27CA%0D%0A%5Cu27CE-%5Cu27D7%0D%0A%5Cu27DA-%5Cu27DF%0D%0A%5Cu27E0-%5Cu27E5%0D%0A%0D%0A%5Cu29B5-%5Cu29C3%0D%0A%5Cu29C4-%5Cu29C9%0D%0A%5Cu29CA-%5Cu29D0%0D%0A%5Cu29D1-%5Cu29D7%0D%0A%5Cu29DF%0D%0A%5Cu29E1%0D%0A%5Cu29E2%0D%0A%5Cu29E3-%5Cu29E6%0D%0A%5Cu29FA%0D%0A%5Cu29FB%0D%0A%0D%0A%5Cu2308-%5Cu230B%0D%0A%5Cu2336-%5Cu237A%0D%0A%5Cu2395%5D> > that > your group identified by hand as operators. It also links to the combined Sm > and So categories > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%5B%3ASm%3A%5D%5B%3ASo%3A%5D%5D>. > However what you actually propose is the far-more-limited Mathematical > Operators block > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock=Mathematical%20Operators%7D> > . > > I will take it upon myself to go through code-points by hand and see what > I can find. > > It is worth noting that your proposed “symbol identifier” category, by its > very name, suggests it should have broader membership than just operators. > I am not sure if that was intentional, however I will restrict my attention > to symbols that may reasonably function as operators. > > After a preliminary glance through the code blocks, I believe there are > operator-like characters in these blocks > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock%3DBasic+Latin%7D%0D%0A%5Cp%7BBlock%3DLatin-1+Supplement%7D%0D%0A%5Cp%7BBlock%3DGeneral+Punctuation%7D%0D%0A%5Cp%7BBlock%3DLetterlike+Symbols%7D%0D%0A%5Cp%7BBlock%3DArrows%7D%0D%0A%5Cp%7BBlock%3DMathematical+Operators%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Technical%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Mathematical+Symbols-A%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Arrows-A%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Arrows-B%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Mathematical+Symbols-B%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Mathematical+Operators%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Symbols+and+Arrows%7D%0D%0A%5Cp%7BBlock%3DSupplemental+Punctuation%7D&g=&i=> > : > Basic Latin > Latin-1 Supplement > General Punctuation > Letterlike Symbols > Arrows > Mathematical Operators > Miscellaneous Technical > Miscellaneous Mathematical Symbols-A > Supplemental Arrows-A > Supplemental Arrows-B > Miscellaneous Mathematical Symbols-B > Supplemental Mathematical Operators > Miscellaneous Symbols and Arrows > Supplemental Punctuation > > Furthermore, the following blocks > <http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5Cp%7BBlock%3DBox+Drawing%7D%0D%0A%5Cp%7BBlock%3DBlock+Elements%7D%0D%0A%5Cp%7BBlock%3DGeometric+Shapes%7D%0D%0A%5Cp%7BBlock%3DMiscellaneous+Symbols%7D%0D%0A%5Cp%7BBlock%3DDingbats%7D%0D%0A%5Cp%7BBlock%3DBraille+Patterns%7D%0D%0A%5Cp%7BBlock%3DCJK+Symbols+and+Punctuation%7D%0D%0A%5Cp%7BBlock%3DYijing+Hexagram+Symbols%7D%0D%0A%5Cp%7BBlock%3DAncient+Symbols%7D%0D%0A%5Cp%7BBlock%3DMusical+Symbols%7D%0D%0A%5Cp%7BBlock%3DTai+Xuan+Jing+Symbols%7D&g=&i=> > *may* have symbols that we want to allow in operators: > Box Drawing > Block Elements > Geometric Shapes > Miscellaneous Symbols > Dingbats > Braille Patterns > CJK Symbols and Punctuation > Yijing Hexagram Symbols > Ancient Symbols > Musical Symbols > Tai Xuan Jing Symbols > > I think that covers all the blocks with potentially operator-like > characters. When I have had time to go through character by character I > will report back my findings. > A previous version of our proposal went through these blocks character-by-character. It was not a fruitful exercise, and absent a compelling use case, I would not recommend it, as Jonathan has made clear that whatever UAX#31 ends up doing, it's definitely the case that Unicode will not be adopting this character-by-character approach. > Nevin > > > > On Sat, Oct 22, 2016 at 12:59 AM, Jonathan S. Shapiro via swift-evolution > <swift-evolution@swift.org> wrote: > >> All: >> >> Jacob has already identified a *big* hole in the proposal, which is that >> it doesn't define how operator-bound identifiers are treated by import. >> That definitely needs to be addressed by the proposal. It's >> straightforward, but easy to get wrong. I will address that early tomorrow. >> >> >> 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 > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution