<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">As Stage 2 of Swift 4 evolution starts now, I'd like to share a revised proposal in draft form.<div class=""><br class=""></div><div class="">It proposes a source-breaking change for <b class="">rationalizing</b> which characters are permitted in identifiers and which in operators.</div><div class=""><br class=""></div><div class="">What feedback would be<b class=""> most helpful</b>:</div><div class=""><br class=""></div><div class="">- "Hey, this approach is so much more <b class="">clumsy</b> than my superior, more elegant category-based approach to identifying [operators/emoji], which is [insert here]."<br class=""></div><div class="">- "Hey, I disagree with the detailed design because it's got a <b class="">major security hole</b>, which is [insert here]."</div><div class="">- "Hey, your proposal would break my <b class="">real-world</b> Swift code, which requires that character [X] be an [identifier/operator]."</div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>* 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?</div><div><br class=""></div><div>* 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).</div><div><br class=""></div><div>* 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:</div><div><br class=""></div><div>- Identifiers under Swift 3 and this proposal: 120,617 code points</div><div>- Identifiers that would be added under this proposal: 699 emoji</div><div>- Identifiers under Swift 3 that would no longer be an identifier: unassigned code points and 4,929 other code points</div><div><br class=""></div><div>Similarly, for operators:</div><div><br class=""></div><div>- Operators under Swift 3 and this proposal: 986 code points</div><div>- Operators that would be added under this proposal: \</div><div>- Operators under Swift 3 that would no longer be an identifier: unassigned code points and 2,024 other code points</div><div><br class=""></div><div>You could summarise that as a pseudo-diff --stat</div><div><br class=""></div><div>Identifiers</div><div>+ 699 emoji</div><div> 120,617 code points</div><div>- 4,929 code points and unassigned code points</div><div><br class=""></div><div>Operators</div><div>+ 1 code point \ </div><div> 986 code points</div><div>- 2,024 code points</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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. </div><div><br class=""></div><div>Alex</div></body></html>