<div dir="ltr">Perhaps a more general solution would be a way to mark functions as “rearrangeable”, meaning the arguments can appear in any order.<div><br></div><div>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.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 14, 2016 at 6:48 AM, Haravikk via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm a +1 on the feature, though for simply handling symmetry it's not a super critical issue.<br>
<br>
<br>
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?<br>
<br>
I was thinking recently it would be convenient if I could define say a 3-dimensional point like so: <x, y, z><br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
> On 14 Nov 2016, at 09:57, Dimitri Racordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> +1<br>
><br>
> I think the use cases are not that sparse actually.<br>
> 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.<br>
><br>
><br>
><br>
>> On 14 Nov 2016, at 10:51, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> -1<br>
>> Not worth adding syntactic sugar for a narrow use case. Plus it's an additive feature.<br>
>> ______________________________<wbr>_________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
><br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>