<div dir="ltr">That&#39;s an interesting issue, I think you&#39;re right. Technically I think it would only be a problem if you omitted spaces: &quot;a&lt;$&gt;b&quot;, since infix identifiers aren&#39;t allowed to have a space on one side but not the other (thus &quot;a &lt;$&gt; b&quot; couldn&#39;t be &quot;&gt;(&lt;(a, $), b)&quot;, but &quot;a&lt;$&gt;b&quot; could).<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Jacob<br></div></div></div></div>
<br><div class="gmail_quote">On Sun, Jan 3, 2016 at 6:27 PM, Félix Cloutier <span dir="ltr">&lt;<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I&#39;m routinely proven wrong, but if $ was allowed to be either an operator or an identifier, it seems to me that `a &lt;$&gt; b` could produce two different and (potentially) valid ASTs depending only on whether &lt;$&gt; exists as an operator. Some people don&#39;t like operator overloading, imagine if you told them that they can&#39;t even be sure that what they&#39;re looking at is an operator at all.</div><br><div>
<span style="border-collapse:separate;color:rgb(0,0,0);font-family:&#39;Lucida Grande&#39;;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Félix</span>
</div>

<br><div><blockquote type="cite"><div><div class="h5"><div>Le 3 janv. 2016 à 21:02:40, Jacob Bandes-Storch via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :</div><br></div></div><div><div><div class="h5"><div dir="ltr">Is it considered infeasible for any characters to be allowed in both identifiers and operators?<div class="gmail_extra">
<br><div class="gmail_quote">On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
&gt; On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`.  I don&#39;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.<br>
&gt;<br>
&gt; I believe the reason you don&#39;t see any other $ variables is that they&#39;re reserved for the debugger and REPL.<br>
&gt;<br>
&gt;       brent@Brents-MacBook-Pro ~/D/Code&gt; swift<br>
&gt;       Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.<br>
&gt;         1&gt; &quot;foo&quot;<br>
&gt;       $R0: String = &quot;foo&quot;<br>
&gt;         2&gt; print($R0)<br>
&gt;       foo<br>
<br>
</span>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.<br>
<br>
-Chris<br>
<div><div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k5LPG17W-2BjSQM-2F0TVqZpS8FL3-2FSisz-2BB6Z8EnrxHxTGd0TE2E9sL7Q49MNGhaQOjlIMtqg2pH67F1flQaRfyWAY5dQJBgbjOcLhcqDb0dCXfcRUfhcTZz364kNRHshQn8MBsd3RhzJL4y438Ie4DxNVNFIY5lkF-2BBysIZckJwY-2F5lFtcPz7lDMGICkpds0RtEc-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<span class=""><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></blockquote></div><br></div></div>