<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 20, 2016 at 4:02 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> On Oct 20, 2016, at 12:25 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> These can be used as identifiers unless they have been defined as an operator somewhere within the project, at which point they switch to being only usable as operators.<br>
<br>
</span>Imagine you're the compiler and you've been handed this source file:<br>
<br>
let party = 🎉🎂<br>
prefix operator 🎉<br>
<br>
You're going to see a keyword "let", an identifier "party", an "=" operator, and then the sequence "🎉🎂". How will you interpret that sequence? There are a few possibilities:<br>
<br>
1. A two-character variable named "🎉🎂".<br>
2. A prefix "🎉" operator followed by a one-character variable name "🎂".<br>
3. A two-character operator "🎉🎂" with an operand to follow on the next line.<br>
4. A one-character variable name "🎉" followed by a postfix "🎂" operator.<br>
<br>
The operator declaration on the next line will make all of this clear—but we can't understand the next line until we've parsed this line (see #3).<br></blockquote><div><br></div><div>Nope. There is no scenario in which any of this is clarified by an operator declaration, and certainly one that is not in the lexical scope. What would happen is this:</div><div><br></div><div>1. At the LEXICAL level, the sequences 🎉🎂 will be handled according to the tokenization rules. If emojis are admitted in Swift, they are definitely in the identifier space, so both of these are "normal" identifiers.</div><div><br></div><div>2. At the parse level, no operator is in scope when you encounter the 🎉🎂, so it's simply an identifier. </div><div><br></div><div>3. At symbol resolution, no binding is found for that identifier, and an error is raised.</div><div><br></div><div>Now let's consider real examples:</div><div><br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div>let c = a +++ b /// +++ is a user infix operator</div></div></div></blockquote><div><br></div>Fails, because +++ is not defined in the lexical scope.<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>func +++ (a, b) -> int { ...}</div><div>...</div><div>let c = a +++ b</div></blockquote><div><br></div><div>fails because this tokenizes as LET ident = ident ident ident, which is a parse error. So how about:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>func +++ (a, b) -> int { ...}</div><div>...</div><div>let c = +++(a, b)</div></blockquote><div><br></div><div>succeeds. Tokenizes as LET ident = ident ( ident, ident), which is a function call. OK. Now how about;</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>infix operator +++ : *SomePrecedence*</div><div>...</div><div>let c = a +++ b</div></blockquote><div><br></div><div>builds a parse tree in which +++ is bound in the lexical contour of operator symbols, but fails because +++ is <i>not</i> bound in the lexical contour of identifiers. What was needed was</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>func +++(a, b) -> int { ... }</div><div>infix operator +++ : *SomePrecedence*</div><div>...</div><div>let c = a +++ b</div></blockquote><div><br></div><div>THIS works. Builds an operator expression parse tree because +++ is bound in the lexical contour of operator reserved words. Identifier resolution then succeeds because +++ is <i>also</i> bound in the lexical contour of identifiers.</div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But this would be very strange in Swift, which is otherwise completely insensitive to the order of statements in a declaration scope. And it leads to a strange two-phase behavior when parsing multiple files: You would need to parse each file through the end of its operator declarations before parsing any other code in any of the other files.</blockquote><div><br></div><div>If I understand the language reference correctly, what you say is true within a class definition, but not at file or local scope. Normal scopes follow the normal rules for lexical contours. Member scopes have something like the behavior you suggest, but the rules there are more complex than you are describing.</div><div><br></div><div><br></div><div>Jonathan </div></div></div></div></div>