That's an interesting issue, I think you're right. Technically I think it would only be a problem if you omitted spaces: "a<$>b", since infix identifiers aren't allowed to have a space on one side but not the other (thus "a <$> b" couldn't be ">(<(a, $), b)", but "a<$>b" could).
Jacob On Sun, Jan 3, 2016 at 6:27 PM, Félix Cloutier <[email protected]> wrote: > I'm routinely proven wrong, but if $ was allowed to be either an operator > or an identifier, it seems to me that `a <$> b` could produce two different > and (potentially) valid ASTs depending only on whether <$> exists as an > operator. Some people don't like operator overloading, imagine if you told > them that they can't even be sure that what they're looking at is an > operator at all. > > Félix > > Le 3 janv. 2016 à 21:02:40, Jacob Bandes-Storch via swift-evolution < > [email protected]> a écrit : > > Is it considered infeasible for any characters to be allowed in both > identifiers and operators? > > On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution < > [email protected]> wrote: > >> >> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution < >> [email protected]> wrote: >> > >> >> Swift currently does not allow operators to use $ - I assume because >> the grammar reserves it in one place: `implicit-parameter-name`. I don't >> see why an entire class of identifiers has been eliminated, so I propose $ >> instead be reclassified as an `operator-character` so it can be used mixed >> in with other such characters, but prevents the introduction of >> `$Identifier`-style declarations that might conflict with implicit >> parameters. >> > >> > I believe the reason you don't see any other $ variables is that >> they're reserved for the debugger and REPL. >> > >> > brent@Brents-MacBook-Pro ~/D/Code> swift >> > Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 >> clang-700.1.81). Type :help for assistance. >> > 1> "foo" >> > $R0: String = "foo" >> > 2> print($R0) >> > foo >> >> Right. That said, our current operator space (particularly the unicode >> segments covered) is not super well considered. It would be great for >> someone to take a more systematic pass over them to rationalize things. >> >> -Chris >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
