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

Sat Oct 22 01:37:14 CDT 2016

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 at gmail.com> wrote:

> On Fri, Oct 21, 2016 at 1:54 PM, Nevin Brackett-Rozinsky via
> swift-evolution <swift-evolution at 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=\p{Block=Mathematical%20Operators}>
.

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.

Nevin

On Sat, Oct 22, 2016 at 12:59 AM, Jonathan S. Shapiro via swift-evolution <
swift-evolution at 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 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/20161022/f6bf015d/attachment.html>