[swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

[Xiaodi Wu]

On Mon, Feb 20, 2017 at 12:29 PM, Alex Blewitt <alblue at apple.com> wrote:

>
> On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
> What feedback would be* most helpful*:
>
> - "Hey, this approach is so much more *clumsy* than my superior, more
> elegant category-based approach to identifying [operators/emoji], which is
> [insert here]."
> - "Hey, I disagree with the detailed design because it's got a *major
> security hole*, which is [insert here]."
> - "Hey, your proposal would break my *real-world* Swift code, which
> requires that character [X] be an [identifier/operator]."
>
>
> I like the approach taken here, and it is a much better way of concluding
> the characters. I don't disagree with the design and don't have any example
> code that will be affected, but I do have some (minor) observations about
> the proposal.
>

Thanks Alex! I've updated the document accordingly. Here's the link:
https://github.com/xwu/swift-evolution/blob/d1643c5c451232a277fe77b22fb891cdae90dcb4/proposals/NNNN-refining-identifier-and-operator-symbology.md


> * The 'Dots' treatment feels like a special case in an otherwise good
> write-up of Unicode, seemingly to lean towards Dart's method chaining
> and/or cleanliness of implementation. It might be clearer to pull that out
> to its own proposal, either independent of or building upon the general
> Unicode changes?
>

Excellent point. I've removed mentions of method cascades. The rationale
for revising the "dots rule" is clarified in the context of alignment to
Unicode (or more accurately here, skating to where Unicode will be).

* The grammar changes for the operator head contain a number of (what seems
> like) hand-picked unicode symbols for increased compatibility with Swift 3
> (e.g. dagger and friends). Maybe these could be pulled out into their own
> group e.g. operator-head -> operator-head-swift3, to call out the reason
> for their hand-picked nature (and for later cleanup, should that be
> required).
>

Done.


> * The proposed solution tables (shall be an identifier/is an identifier)
> wasn't clear to me at first what the rows and columns were. Maybe calling
> these out as a bulleted list would be better:
>
> - Identifiers under Swift 3 and this proposal: 120,617 code points
> - Identifiers that would be added under this proposal: 699 emoji
> - Identifiers under Swift 3 that would no longer be an identifier:
> unassigned code points and 4,929 other code points
>
> Similarly, for operators:
>
> - Operators under Swift 3 and this proposal: 986 code points
> - Operators that would be added under this proposal: \
> - Operators under Swift 3 that would no longer be an identifier:
> unassigned code points and 2,024 other code points
>
> You could summarise that as a pseudo-diff --stat
>
> Identifiers
> + 699 emoji
>   120,617 code points
> - 4,929 code points and unassigned code points
>
> Operators
> + 1 code point \
>   986 code points
> - 2,024 code points
>
> Alternatively you could change the 'Is an identifier/operator' to 'Is a
> Swift 3 identifier' to make it clear that it's the Swift 3 header, but the
> tabular form is still not that clear to me.
>

I've converted this to bulleted lists like you suggest.


> Another stat that would be worth calling out: of the 2,042 code points
> that are no longer operators, what the overlap is with the 699 emoji that
> are added to the identifiers? If they were all of them then it would only
> be 1,325 operators that were no longer valid.
>

The answer to that is 98; the 601 are emoji sequences that weren't
permitted previously. I've incorporated this information into the text.


> To conclude: I like the look of the proposal from the block set
> definition, which will be better than hand-picking the character set as the
> grammar currently stands.
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/efa5af4a/attachment.html>