David, what about un-labeled parameters? If a function has 2 parameters of the
same type, how does compiler know which ones's which?
> On Nov 13, 2016, at 9:49 PM, David Sweeris via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Nov 13, 2016, at 1:38 PM, Андрей Володин via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Hi, list!
>>
>> I’m thinking about proposal that would add a possibility to save some time
>> on creating symmetrical binary operators.
>>
>> The latest code example from my math lib:
>>
>> @inline(__always)
>> public static func *(lhs: Angle, rhs: Float) -> Angle {
>> return Angle(lhs.degrees * rhs)
>> }
>>
>> @inline(__always)
>> public static func *(lhs: Float, rhs: Angle) -> Angle {
>> return Angle(rhs.degrees * lhs)
>> }
>>
>> The API of Angle doesn’t really matter here, what’s important is that I have
>> to write another operator to make it symmetrical. Not so hard: 3 lines of
>> code. It can even refer to original implementation, instead of duplicating
>> the logic. But I think it would be nice to have something like symmetrical
>> keyword, just like we have associativity and precedence.
>>
>> I also bet that all operators should be asymmetrical by default.
>>
>> Any thoughts?
>
> I fully support adding a “@commutative” attribute or something to let the
> compiler know that a function can be called with its arguments out of order,
> but I’m thoroughly against turning it on by default. Some operations, such as
> matrix multiplication, aren’t even defined if you swap the arguments.
>
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
