> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution > <[email protected]> wrote: > > >> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution >> <[email protected]> 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 >>> <[email protected]> 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 >>>> <[email protected]> wrote: >>>> >>>> -1 >>>> Not worth adding syntactic sugar for a narrow use case. Plus it's an >>>> additive feature. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > Commutative operators are very common and I would definitely +1 a shorthand > for them. > > You seem to be talking about a custom literal, rather than an operator - you > said you want to “define” a point with some special syntax. Try > ArrayLiteralConvertible.
The problem is there’s no way to conform to ArrayLiteralConvertible only when a certain # of elements are present, and the protocol requires the init function to not be failable. In this particular case you can fake it by only copying the first 3 values from the array and using 0 to fill in missing elements. It could be argued that filling in the 0s is “correct enough”, but throwing out extra elements is certainly bad. And you’re still in the (undesirable, IMHO) position of using run-time checks to account for what amounts to a syntax error that should be easy to catch at compile-time. - Dave Sweeris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
