<div dir="ltr">Some other languages provide special syntax to use a binary function as infix:<div><br></div><div><br></div><div>Haskell:</div><div> foo a b -- is equivalent to</div><div> a `foo` b</div><div><br></div><div>Mathematica:</div><div> Foo[a, b] (*is equivalent to*)</div><div> a~Foo~b</div><div><br></div><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 Thu, Jan 7, 2016 at 9:42 PM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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"><span class=""><br><div><blockquote type="cite"><div>On Jan 7, 2016, at 5:26 PM, Jo Albright <<a href="mailto:me@jo2.co" target="_blank">me@jo2.co</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"><div><div><div><div>Chris - I really appreciate that you take the time to entertain & respond to proposals. </div></div></div></div><div><br><blockquote type="cite" style="font-weight:normal"><div>On Jan 7, 2016, at 7:24 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jan 7, 2016, at 1:31 AM, Jo Albright via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div>As my obsession grows with custom operators. I have come across wanting to use small words or 1-2 alphabetical characters as custom operators. I noticed that “as” and “is” are character based operators and figured it wouldn’t hurt to propose the allowance of character based custom operators.</div><div><br></div><div>Here are my reasons for allowing them:</div><div><br></div><div>1. easier to read “within” vs “><span style="font-family:Menlo;font-size:11px">*</span><“ or “|<span style="font-family:Menlo;font-size:11px">*</span>|” </div></div></div></blockquote><div><br></div></div>Check out Replace Logical Operators (&&, ||, etc) with words like "and" and “or":<div><a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a></div></div></div></blockquote><div style="font-weight:normal"><br></div>I completely agree with that proposal being rejected. I am not asking to replace existing language grammar. My desire is for the support of alphabetical characters for custom operators to allow <b>third party libraries</b><b style="font-weight:normal"> </b>to have their own unique grammar.<br> <br><blockquote type="cite" style="font-weight:normal"><div style="word-wrap:break-word"><div>There is very small win here of “x foo y” over "x.foo(y)”?</div></div></blockquote><div style="font-weight:normal"><br></div><div style="font-weight:normal">And I completely agree that function/method syntax can easily suffice for normal circumstances. Just trying to see how far Swift can be stretched.</div></div></span></div></div></div></blockquote><br></div></span><div>Hi Jo,</div><div><br></div><div>The rationale is the same - the design of Swift really wants operators and identifiers to be partitioned into different namespaces. Violating that would make it impossible to parse a swift file without parsing all of its imports. This is a mistake that C made (you have to parse all the headers a file uses to reliably parse the file) that we don’t want to replicate in Swift.</div><div><br></div><div>-Chris</div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=P-2BsYbBZHRBuLDBJaL4DIKDNfkkjpROowTyRAObV11qz6m7-2BHSGYzfIQfSW-2BuN0gBqpHFRkjQ9HVyupfGLXuogvmqXVOM26YtFfoy38VsGF6LTUdk-2BR-2FEVuQqNfmCtT-2F6KltcIGMZUIS3Wk1BnFMRvoH28Ractx1RTbNrWNy1oYNgd65VJch3c-2BOLwL9ch01cs-2FeayrSoTCe5uzyTk-2BBb7Oj5gWartJerl3txp16r3aA-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">
</div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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>
<br></blockquote></div><br></div></div>