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

[Jacob Bandes-Storch]

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 <felixcca at yahoo.ca> 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 <
> swift-evolution at swift.org> 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 <
> swift-evolution at swift.org> wrote:
>
>>
>> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <
>> swift-evolution at 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 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 at 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
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160103/3da876c0/attachment.html>