> On Oct 20, 2016, at 9:37 AM, Jonathan S. Shapiro
> <jonathan.s.shap...@gmail.com> wrote:
>
> On Thu, Oct 20, 2016 at 7:30 AM, David Sweeris <daveswee...@mac.com
> <mailto:daveswee...@mac.com>> wrote:
> Sent from my iPhone
>
> On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution
>> <swift-evolution@swift.org <mailto: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.
>
> The hard requirements are:
> Nothing in identifier start can be in operator start or operator continue. [*]
> Nothing in operator start can be in identifier start or identifier continue.
> [*]
> Nothing in syntactic punctuation (period, brackets, parens, and so forth) can
> be in either type of identifier without creating a lot of serious hair. You
> can see one example of hair in the "double dots" rule.
> If these requirements are not preserved, the consequence is that white space
> becomes required between identifiers and operators. So, for example, without
> these rules:
>
> a+b // gets broken
> a + b // works
>
> The presence of dots in operators is actually causing a whole bunch of
> constraints to get introduced that I'm going to talk about in a moment.
Ah, ok. Your explanation sounds very familiar… Clearly I’ve read it before and
forgot. I must be going senile in my old age (37).
Would this whitespace rule affect pre/postfix operators, or just the infix
ones? Personally, I’m fine with requiring whitespace around infix operators,
but pre/postfix operators would completely lose readability if they needed it,
too. Have we previously discussed this on the mailing list?
Given my apparent forgetfulness, I have no doubt that we discussed it at length
two weeks ago, and someone will probably reply to this, quoting some forgotten
3-page email I sent on the topic :-)
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
