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

Joe Groff jgroff at apple.com
Fri Jan 8 13:49:17 CST 2016


> On Jan 7, 2016, at 9:49 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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

You could implement the Mathematica one yourself:

operator infix ~ { associativity left }

struct Section<T, U, V> { var lhs: T, op: (T,U) -> V }

func ~<T, U, V>(lhs: T, op: (T, U) -> V) -> Section<T,U,V> {
  return Section(lhs: lhs, op: op)
}

func ~<T, U, V>(section: Section<T, U, V>, rhs: U) -> V {
  return section.op(section.lhs, rhs)
}

though I don't really see how x `foo` y is a real improvement over x.foo(y).

-Joe

> 
> Jacob
> 
> On Thu, Jan 7, 2016 at 9:42 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Jan 7, 2016, at 5:26 PM, Jo Albright <me at jo2.co <mailto: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 <mailto:clattner at apple.com>> wrote:
>>> 
>>> 
>>>> On Jan 7, 2016, at 1:31 AM, Jo Albright via swift-evolution <swift-evolution at swift.org <mailto: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 <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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160108/fd250f45/attachment.html>


More information about the swift-evolution mailing list