I thought limiting the keywords to the ones explicitly defined for this purpose would solve the problem of overcomplicating the parser. Just to be clear: I do *not* propose replacing punctuation-based operators with identifier-based ones, the ideas was purely additive. But I do see the problem now. I can't think of a good way at the moment of resolving the recursive problem with the parser if it needs to resolve the imports first. Perhaps If I come up with a deterministic and easy parsing mechanism that would not depend on pre-arsing the entire file at once, this would not be such a bit show-stopper. And again, I wouldn't even bring this up if swift didn't already rely on keyword operators, which means that there can not be any semantical reason to disallow this.
> On Aug 1, 2017, at 4:29 AM, Chris Lattner <[email protected]> wrote: > > >> On Jul 31, 2017, at 2:09 PM, Gor Gyolchanyan via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> So I was thinking the other day (and by "the other day" I mean "It just >> occurred to me") that Swift's custom operator declaration mechanism is >> pretty sweet (it's become even sweeter ever since numeric precedence values >> were replaced with purely relativistic precedence trees). There are >> currently only two problems with them that grind my operator-declaring >> endeavors to a painful halt: >> 1. The fact that most punctuation characters on the keyboard (think - >> ASCII) are reserved, so any custom operator either has to be a long sequence >> of two or three non-reserved ASCII characters or have to include >> difficult-to-type unicode punctuation characters. >> 2. The fact that anything that passes as an identifier character (which >> includes a surprisingly wide array of punctuation characters) is off the >> table as well. > > See the 3rd entry of: > https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md > <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md> > > -Chris > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
