> On Nov 16, 2016, at 10:35, Stephen Canon <[email protected]> wrote:
>
>
>>> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution
>>> <[email protected]> wrote:
>>>
>>>
>>>> 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.
>
> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
