[swift-evolution] Symmetrical operators

[David Sweeris]

> On Nov 16, 2016, at 10:35, Stephen Canon <scanon at apple.com> wrote:
> 
> 
>>> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>>> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>> On 14 Nov 2016, at 12:48, 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
>>> 
>>> 
>>> 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.
> 
> You can make it a precondition that the array have the right number of elements; this is what the simd module types on Apple platforms do, for example:
> 
> 	1> import simd
> 	2> let w = [1,2,3,4] as float3
> 	fatal error: float3 requires a three-element array
> 
> but you're still left with a run-time error rather than a syntax-error, which is definitely not ideal.

Oh! Good idea! Dunno why I hadn't thought of that :-)



Should this "custom operator grammar/syntax" part of the discussion get its own thread, or is it sufficiently related to the OP's "symmetry" idea?

- Dave Sweeris, who is aware that his deep and abiding love of exploring all the rabbit trails is probably quite a lot stronger than most people's, and doesn't want to unduly inflict his ADD on the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161116/d80d12c9/attachment.html>