But is there anything actually wrong with the way it is today?
On Tue, Jul 12, 2016 at 3:22 AM, Anton Zhilin via swift-evolution < [email protected]> wrote: > Why don't we go the other direction? Example: > > func ^^(prefix: Int) {} > func ^^(postfix: Int) {} > func ^^(lhs: Int, rhs: Int) {} > > We will make 'prefix', 'postfix' and perhaps 'lhs' and 'rhs' required > external parameter names for operator functions. > > 2016-07-12 7:03 GMT+03:00 Jacob Bandes-Storch via swift-evolution < > [email protected]>: > >> Currently, "infix" is not required/allowed on an operator function >> definition, but "prefix" and "postfix" are: >> >> prefix operator ^^ {} // valid >> postfix operator ^^ {} // valid >> infix operator ^^ {} // valid >> >> prefix func ^^(operand: Int) {} // valid >> postfix func ^^(operand: Int) {} // valid >> infix func ^^(lhs: Int, rhs: Int) {} // *error: *'infix' modifier >> is not required or allowed on func declarations >> func ^^(lhs: Int, rhs: Int) {} // valid >> >> It seems like this was removed because it can be inferred from the number >> of arguments ( >> https://github.com/apple/swift/commit/3ad9c58c18f0331444114e2eae3e772e702c326f). >> But IMO the inconsistency from other operator function decls/defs is >> jarring. >> >> How does everyone feel about reinstating the "infix" modifier on >> functoins? (It was removed before the open-source release and the advent of >> swift-evolution, so I thought it'd be worth a public review.) >> >> Jacob >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
