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

[Joe Groff]

> On Oct 24, 2016, at 10:15 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> 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> 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.

Yeah, that's a tradeoff. I think that requiring non-standard operator use to be explicitly declared could be a good thing, though, since I don't think that we can realistically expect users to learn or intuitively agree on what glyphs are "operator" or "identifier", no matter what character set we design.

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

As long as { } aren't in the operator character set, we should still be able to skip function bodies without parsing, so operator use declarations could still be order-independent at the top level of declarations. (Whether it's a good idea to bury your import declarations in the middle of your other decls is another story.)

-Joe