Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Jacob Bandes-Storch via swift-evolution
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,

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Jacob Bandes-Storch via swift-evolution
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 < swift-evolution@swift.org> wrote: > > > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution < >

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Chris Lattner via swift-evolution
We need a token to be unambiguously an operator or identifier - we can have different rules for the leading and subsequent characters though. -Chris > On Jan 3, 2016, at 6:02 PM, Jacob Bandes-Storch wrote: > > Is it considered infeasible for any characters to be allowed in

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Michel Fortin via swift-evolution
Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution a écrit : > As I recall it, there is no overlap between operator characters and > identifier characters. If it's not in the operator set, it's effectively > reserved for identifiers. It's funny that ¢, £,

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Kevin Ballard via swift-evolution
On Sun, Jan 3, 2016, at 12:55 PM, Michel Fortin via swift-evolution wrote: > Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution > a écrit : > > As I recall it, there is no overlap between operator characters and > > identifier characters. If it's not in the

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread John Joyce via swift-evolution
I have been thinking about this topic a lot, but not '$' symbol, rather the tools to create DSLs within Swift to enable productive & meaningful special casing. (Ruby's Rake vs Make/GNUMake come to mind a lot, or Ruby's Sinatra web framework come to mind, perhaps Python's Flask to a lesser

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Developer via swift-evolution
Well, that's just it. $ is a perfectly valid character in identifiers everywhere but in the grammar for operators for some reason. It isn't reserved, it just isn't there. ~Robert Widmann 2016/01/03 0:53、Brent Royal-Gordon のメッセージ: >> Swift currently does not allow

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Félix Cloutier via swift-evolution
As I recall it, there is no overlap between operator characters and identifier characters. If it's not in the operator set, it's effectively reserved for identifiers. I also remember someone from Apple confirming what Brent said but I can't find it at the moment. Félix > Le 3 janv. 2016 à

[swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-02 Thread Developer via swift-evolution
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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-02 Thread Jacob Bandes-Storch via swift-evolution
+10 On Sat, Jan 2, 2016 at 11:36 PM, Developer via swift-evolution < swift-evolution@swift.org> 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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-02 Thread Brent Royal-Gordon via swift-evolution
> 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