> On 17 Feb 2017, at 05:50, Xiaodi Wu via swift-evolution > <swift-evolution@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. * 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? * 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). * 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. 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. 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
