Sent from my iPhone
> On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Freeze the set of allowed emoji to whatever the current version of the
>> Unicode spec defines...
>
> UAX31 won't include emojis in either space, because there is no clear
> consensus about where they belong (identifiers or operators). Individual
> languages can certainly add them to one space or the other, but should take
> care not to cross-contaminate. So if we add them to operators, we need to
> exclude any that are already part of normal identifiers and vice versa. That
> sanity restriction is technically necessary, but it shouldn't be an
> inconvenience in practical terms.
My understanding (which is admittedly fuzzy) is that the distinction between
operators and identifiers is only "technically necessary" because allowing
characters to be both causes the parsing algorithm lose its virtual mind, and
it takes a century for it to figure out what's going on. What I don't recall
being discussed before is whether that's a blanket penalty or if the compile
times increases are proportional to the amount overlap between the two
character sets. If it's the latter, it might be worth discussing whether we
should allow a *small* group of characters to be legal as both identifiers or
operators, while maintaining sub-century compile times.
- Dave Sweeris.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
