<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><div><br><br>Sent from my iPhone</div>On Oct 25, 2016, at 10:24, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><blockquote type="cite">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.</blockquote><span></span><br><span>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.</span><br></div></blockquote>I could get behind having to explicitly import operators:<div> import CoolLib</div><div> import operators CoolLib</div><div>or</div><div> import CoolLib {types functions vars operators}<br><div>But having to re-declare every "non-standard" operator for every file <i>really</i> limits their usefulness, IMHO.</div><br><blockquote type="cite"><div><span>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.)</span><br></div></blockquote>Oh, is using {} as operators on the table? There's gotta be some interesting syntax someone could make with those...</div><div><br></div><div>- Dave Sweeris</div></body></html>