<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 24, 2016, at 9:40 AM, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 22, 2016, at 5:53 PM, Jonathan S. Shapiro &lt;<a href="mailto:jonathan.s.shapiro@gmail.com" class="">jonathan.s.shapiro@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I missed this earlier posting from Joe Groff, who wrote:<br class=""><div class="gmail_extra"><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In the discussion about operators, I wonder whether it makes sense to formally separate "identifier" and "operator" characters at all. ...</blockquote><div class=""><br class=""></div><div class="">The consequence if we do not formally separate the operators (verbs) from the identifiers (nouns) is that white space will be needed around all operators. That's not necessarily a bad thing, but it would be a significant and incompatible departure from today's Swift, both in terms of actual source code breakage and in terms of the "look and feel" that many people feel passionate about.</div></div></div></div></blockquote><br class=""></div><div class="">That's not a strict requirement. If we require operator usage to be declared explicitly, the lexer can accommodate those declarations. Since operators only appear as part of expressions inside bodies, the operator import or declaration doesn't even necessarily have to be ordered at the top of the file since we can still skip function bodies when parsing declarations (though I think we'd want to encourage imports on top anyway for the benefit of readers). This wouldn't be unprecedented—operators as they stand already effectively require an extra pass of parsing.</div></div></div></blockquote><br class=""></div><div>Ok, but to clarify the requirement, *every* file would have to declare the operators it is using at the top of the file. &nbsp;It isn’t enough for them to be declared in some file within the current module. &nbsp;Not having this property breaks the ability to do a quick parse of a file without doing name lookup.</div><div><br class=""></div><div>In addition to the tooling impact, going with such an approach would be very inconsistent with the rest of Swift’s grammar, which aims to be order independent (except in script files / top level code).</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>