[swift-evolution] Symmetrical operators

[Nevin Brackett-Rozinsky]

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 at 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 at 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 at 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 at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20161114/dcea5fe9/attachment.html>