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

[Dennis Lysenko]

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.

On Sat, Jan 9, 2016, 1:53 PM Chris Lattner <clattner at apple.com> wrote:

> On Jan 8, 2016, at 2:43 PM, Dennis Lysenko <dennis.s.lysenko at gmail.com>
> wrote:
>
> Jo, maybe it's time to explore infix functions as a potential solution? I
> don't see infix functions under the commonly proposed list.
>
> I just added them.  To repeat what has been said several times on this
> thread, the problem being solved here is not important enough to be worth
> complicating the language for.
>
> -Chris
>
>
>
> On Fri, Jan 8, 2016, 4:28 PM Jo Albright via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I promise, this is my last idea to be thrown at this. Instead of
>> characters in operators...
>>
>> Would the core team be open to having an *operatoralias* keyword that
>> allows an operator to be masked by an identifier.
>>
>> Learning & Teaching Example :
>>
>> operatoralias plus = +
>>
>> let apples = 5 + 5
>> let apples = 5 plus 5
>>
>> With extension :
>>
>> let apples = 5 . plus ( 5 )
>>
>>
>> ---------------------------------------------------------------------------------
>>
>> Learning & Teaching Example :
>>
>> operatoralias incrementedBy = +=
>>
>> updatedValue += 10
>> updatedValue incrementedBy 10
>>
>> With extension :
>>
>> updatedValue . incrementedBy ( 10 )
>>
>>
>> ---------------------------------------------------------------------------------
>>
>> Readability & Code Reduction Example :
>>
>> typealias Point = (x: CGFloat,y: CGFloat)
>>
>> infix operator >>>> { }
>>
>> func >>>> (lhs: CGContextRef?, rhs: Point) -> CGContextRef? {
>>
>>     CGContextMoveToPoint(lhs, rhs.x, rhs.y); return lhs
>>
>> }
>>
>> operatoralias moveTo = >>>> // operator alias for custom operator
>>
>> let context = UIGraphicsGetCurrentContext()
>>
>> context moveTo (10,10) addLineTo (20,20) strokeWith UIColor.redColor()
>>
>> Or if SVG letters used (less readable, but also less footprint) :
>>
>> context M (10,10) L (20,20) stroke UIColor.redColor()
>>
>> I know this looks a lot like a chained method and very close to the same
>> amount of code to be written… however it is slightly easier to read without
>> all of the function punctuation in between :
>>
>> context.moveTo(10,10)?.addLineTo(20,20)?.strokeWith.(UIColor.redColor())
>>
>>
>> I believe there is an opportunity here that won’t truly be appreciated
>> until it is in use. But will not argue that it is very close to what is
>> currently available and does not have a huge impact in the current vision
>> of things.
>>
>> Thanks for humoring my imagination. :)
>>
>>
>>  Nerd . Designer . Developer
>> Jo Albright
>>
>>
>> On Jan 8, 2016, at 2:26 PM, Chris Lattner <clattner at apple.com> wrote:
>>
>>
>> On Jan 7, 2016, at 9:49 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
>> 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
>>
>>
>> Ok, then yes, introducing a magic syntax would be technically feasible
>> (though not backticks, since they are used for something else).
>>
>> This is still extremely unlikely to be accepted though.  Additional
>> language complexity needs to pay for itself, and the win here is so small
>> that it doesn’t seem worth 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/20160109/a6bdfd73/attachment.html>