SDGGiesbrecht
(Jeremy David Giesbrecht)
March 13, 2019, 10:48pm
8
Thanks. I had search, but I guess I picked the wrong search terms. Knowing there must be some threads and being more persistent allowed me to find several. I’ll post links here in chronological order for others who land here. (I actually haven’t read the threads yet. I will now.)
*TL;DR:*
Swift 4 Stage 1 seeks to prioritize "Source stability features". Most
source-breaking changes were done with in Swift 3; however, the
categorization of Unicode characters into identifiers & operators was never
thoroughly discussed on swift-evolution. This seems like it might be our
last chance, and I think there are some big improvements to be had.
I've gathered some information+thoughts into an early-stage pitch /
pre-proposal. It doesn't really have a conclusion, so I'm hoping …
Dear Swift-Evolution community,
A few of us have been preparing a proposal to refine the definitions of
identifiers & operators. This includes some changes to the permitted
Unicode characters.
The latest (perhaps final?) draft is available here:
We'd welcome your initial thoughts, and will probably submit a PR soon to
the swift-evolution repo for a formal review. Full text follows below.
—Jacob Bandes-Storch, Xiaodi Wu, Erica Sadun, Jonathan Shapiro
Refining Identifier and Operator Sym…
As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised
proposal in draft form.
It proposes a source-breaking change for *rationalizing* which characters
are permitted in identifiers and which in operators. It's justified for
this phase of Swift 4 because:
- Existing grammar, in permitting invisible characters without
security-minded restrictions, can be *actively harmful.*
- A rationalized approach is *superior* to the current approach: by
referencing Unicode standards, …
The core team recently met to discuss PR609 - Refining identifier and operator symbology:
The proposal correctly observes that the partitioning of unicode codepoints into identifiers and operators is a mess in some cases. It really is an outright bug for to be an identifier, but to be an operator. That said, the proposal itself is complicated and is defined in terms of a bunch of unicode classes that may evolve in the “wrong way for Swift” in the future.
T…
1 Like