<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 Oct 20, 2016, at 9:37 AM, Jonathan S. Shapiro <<a href="mailto:jonathan.s.shapiro@gmail.com" class="">jonathan.s.shapiro@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 20, 2016 at 7:30 AM, David Sweeris <span dir="ltr" class=""><<a href="mailto:davesweeris@mac.com" target="_blank" class="">davesweeris@mac.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">Sent from my iPhone</div><span class=""><div class=""><br class="">On Oct 20, 2016, at 09:03, Jonathan S. Shapiro via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div></span><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Oct 20, 2016 at 12:12 AM, Austin Zheng via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""></div></blockquote></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""> Freeze the set of allowed emoji to whatever the current version of the Unicode spec defines...</div></blockquote><div class=""><br class=""></div><div class="">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.</div></span></div></div></div></blockquote><br class=""><div class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">The hard requirements are:</div><div class=""><ol class=""><li class="">Nothing in identifier start can be in operator start or operator continue. [*]</li><li class="">Nothing in operator start can be in identifier start or identifier continue. [*]<br class=""></li><li class="">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.<br class=""></li></ol></div><div class="">If these requirements are not preserved, the consequence is that white space becomes required between identifiers and operators. So, for example, without these rules:</div><div class=""><br class=""></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">a+b // gets broken</div></div></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">a + b // works</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote></div><div class=""><br class=""></div>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).<div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">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 :-)</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></body></html>