Perhaps a more general solution would be a way to mark functions as “rearrangeable”, meaning the arguments can appear in any order.
I also like Haravikk’s idea for “outfix” operators—there are certainly a large number of bracket-type Unicode characters that could be useful in such a role. Nevin On Mon, Nov 14, 2016 at 6:48 AM, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > I'm a +1 on the feature, though for simply handling symmetry it's not a > super critical issue. > > > I wonder though, when you start looking at symmetry is it worth looking at > other patterns? For example, could symmetrical operators be covered by a > broader multi-part operator definition? > > I was thinking recently it would be convenient if I could define say a > 3-dimensional point like so: <x, y, z> > > In this case you're looking at a symmetric operator with two different > components (opening and closing angle brackets) with the ability to take > three arguments. Is there a way we could define and implement something > along these lines? If so it would be very flexible, and potential allow us > to unify all operators into a single format. > > For example, you can thing of a prefix operator as being a leading symbol > plus one argument, while a postfix is one argument plus a trailing symbol, > a binary operator is an argument, a symbol and another argument, a > symmetric operator is a leading symbol, an argument and a trailing symbol > (doesn't have to be identical). > > If we had a means of specifying operators in this way (as a complete > pattern) we could do away with special cases of operators entirely, though > they may be worth keeping for compatibility and as a shorthand. > > > On 14 Nov 2016, at 09:57, Dimitri Racordon via swift-evolution < > swift-evolution@swift.org> wrote: > > > > +1 > > > > I think the use cases are not that sparse actually. > > I would also argue that it would be easier to understand the intent of > the code with some sort of keyword than with a hard copy of each function. > > > > > > > >> On 14 Nov 2016, at 10:51, Anton Zhilin via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> -1 > >> Not worth adding syntactic sugar for a narrow use case. Plus it's an > additive feature. > >> _______________________________________________ > >> swift-evolution mailing list > >> swift-evolution@swift.org > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution