> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>>
>> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution
>>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <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.
– Steve
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
