[swift-evolution] [Proposal] Refining Identifier and Operator Symbology

[Chris Lattner]

> On Oct 24, 2016, at 9:40 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Oct 22, 2016, at 5:53 PM, Jonathan S. Shapiro <jonathan.s.shapiro at gmail.com <mailto:jonathan.s.shapiro at gmail.com>> wrote:
>> 
>> I missed this earlier posting from Joe Groff, who wrote:
>> 
>> In the discussion about operators, I wonder whether it makes sense to formally separate "identifier" and "operator" characters at all. ...
>> 
>> 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.
> 
> 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.

Ok, but to clarify the requirement, *every* file would have to declare the operators it is using at the top of the file.  It isn’t enough for them to be declared in some file within the current module.  Not having this property breaks the ability to do a quick parse of a file without doing name lookup.

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).

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161024/3e101bac/attachment.html>