[swift-evolution] Allowing Characters for use as Custom Operators

[Jacob Bandes-Storch]

Some other languages provide special syntax to use a binary function as
infix:


Haskell:
    foo a b    -- is equivalent to
    a `foo` b

Mathematica:
    Foo[a, b]  (*is equivalent to*)
    a~Foo~b


Jacob

On Thu, Jan 7, 2016 at 9:42 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jan 7, 2016, at 5:26 PM, Jo Albright <me at jo2.co> wrote:
>
> Chris - I really appreciate that you take the time to entertain & respond
> to proposals.
>
> On Jan 7, 2016, at 7:24 PM, Chris Lattner <clattner at apple.com> wrote:
>
>
> On Jan 7, 2016, at 1:31 AM, Jo Albright via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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.
>
> Here are my reasons for allowing them:
>
> 1. easier to read “within” vs “>*<“ or “|*|”
>
>
> Check out Replace Logical Operators (&&, ||, etc) with words like "and"
> and “or":
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
>
>
> 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 *third party
> libraries* to have their own unique grammar.
>
>
> There is very small win here of “x foo y” over "x.foo(y)”?
>
>
> And I completely agree that function/method syntax can easily suffice for
> normal circumstances. Just trying to see how far Swift can be stretched.
>
>
> Hi Jo,
>
> 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.
>
> -Chris
>
>
> _______________________________________________
> 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/20160107/980f5143/attachment.html>