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

[André Videla]

Maybe this wan't the original idea but I have a proposition that is both parseable and useful

Imagine you have this struct
struct Person {
    let name: String
    let age: Int
}

and you want to use an operator to compare their fields because you do that often.
Typically you would do something along those lines:

func <(lhs: Person, rhs: Person) -> Bool {
    return lhs.age < rhs.age
}

func <<(lhs: Person, rhs: Person) -> Bool {
    return lhs.name < rhs.name
}

and then use it like so

let john = Person(name: "John", age: 12)
let steve = Person(name: "Steve", age: 14)

john < steve
john << steve

The point isn't that "<" and "<<" are bad operators for this purpose but that operators quickly become confusing when abused.
I think one great solution would be to allow alphanumeric character after the operator head like so: 

func <age(lhs: Person, rhs: Person) -> Bool {…}

func <name(lhs: Person, rhs: Person) -> Bool {…}

john <age steve
john <name steve

and the grammar would need to be changed to:

operator -> operator-head operator-characters
operator-characters -> operator-characters operator-tail
operator-tail -> operator-characters
operator-tail -> alphanumeric alphanumeric?

or something similar

Extra:
If we extend this idea further we could even imagine nice operators like

john <⎮age⎮ steve
john >⎮name⎮ steve

And I will argue that this is more both readable and desirable than john.compareAge(steve) or john.lessThanAge(steve) even though that's what it years of Obj-C and OOP tells us to do.

> On 10 Jan 2016, at 02:23, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 9, 2016, at 11:56 AM, Dennis Lysenko <dennis.s.lysenko at gmail.com <mailto:dennis.s.lysenko at gmail.com>> wrote:
>> Chris, hmm... Can you really say that this is the only problem that would warrant infix functions? To say what you just seemingly implies that you believe the use cases outlined here are the only reason one would want infix operators, and that the use cases outlined here don't warrant infix functions.
>> 
>> I'm sure there are plenty more reasons for implementing infix functions and I think it would be reactionary to effectively discourage their consideration on the basis of one tangentially related email chain.
>> 
> I’m saying that I cannot personally imagine a use-case compelling enough to make the language more complicated for (including the ones listed on the thread).  If you can, please share them and we can discuss it.
> 
> -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/20160110/5273e16c/attachment.html>