Re: [swift-evolution] Symmetrical operators

2016-11-16 Thread David Sweeris via swift-evolution
> On Nov 16, 2016, at 10:35, Stephen Canon wrote: > > >>> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution >>> wrote: >>> >>> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution wrote:

Re: [swift-evolution] Symmetrical operators

2016-11-16 Thread Stephen Canon via swift-evolution
> On Nov 16, 2016, at 10:47 AM, David Sweeris via swift-evolution > > wrote: > >> >> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution >> > wrote: >> >> >>> On 14

Re: [swift-evolution] Symmetrical operators

2016-11-16 Thread David Sweeris via swift-evolution
> On Nov 16, 2016, at 9:25 AM, Karl via swift-evolution > wrote: > > >> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution >> wrote: >> >> I'm a +1 on the feature, though for simply handling symmetry it's not a >> super critical

Re: [swift-evolution] Symmetrical operators

2016-11-16 Thread Karl via swift-evolution
> On 14 Nov 2016, at 12:48, Haravikk via swift-evolution > 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

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread David Sweeris via swift-evolution
> On Nov 14, 2016, at 5:48 AM, Haravikk via swift-evolution > 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

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread Nevin Brackett-Rozinsky via swift-evolution
Perhaps a more general solution would be a way to mark functions as “rearrangeable”, meaning the arguments can appear in any order. I also like Haravikk’s idea for “outfix” operators—there are certainly a large number of bracket-type Unicode characters that could be useful in such a role. Nevin

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread Andrew Volodin via swift-evolution
Well, I dont actually think it can be considered as a syntax sugar. It requires creating separate function to achieve same effect. This is all about how operators behave in general. > 14 нояб. 2016 г., в 12:51, Anton Zhilin написал(а): > > -1 > Not worth adding

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread Andrew Volodin via swift-evolution
Отправлено с iPhone > 14 нояб. 2016 г., в 12:51, Anton Zhilin написал(а): > > -1 > Not worth adding syntactic sugar for a narrow use case. Plus it's an additive > feature. ___ swift-evolution mailing list

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread Haravikk via swift-evolution
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

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread Dimitri Racordon via swift-evolution
+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 >

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread Anton Zhilin via swift-evolution
-1 Not worth adding syntactic sugar for a narrow use case. Plus it's an additive feature. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Symmetrical operators

2016-11-14 Thread Jonathan Hull via swift-evolution
+1 Not symmetrical by default, but able to add an attribute/keyword to auto-generate a default implementation which swaps the lhs & rhs. > Hi, list! > > I’m thinking about proposal that would add a possibility to save some time on > creating symmetrical binary operators. > > The latest code

Re: [swift-evolution] Symmetrical operators

2016-11-13 Thread David Sweeris via swift-evolution
Although you are correct in that the compiler wouldn't be able to guarantee that both "versions" would give the same answer, but that's currently the case anyway. Sent from my iPhone > On Nov 13, 2016, at 20:03, David Sweeris via swift-evolution > wrote: > > >>

Re: [swift-evolution] Symmetrical operators

2016-11-13 Thread David Sweeris via swift-evolution
> On Nov 13, 2016, at 19:04, arkadi daniyelian wrote: > > David, what about un-labeled parameters? If a function has 2 parameters of > the same type, how does compiler know which ones's which? If a function has two unlabeled parameters of the same type, you can already

Re: [swift-evolution] Symmetrical operators

2016-11-13 Thread arkadi daniyelian via swift-evolution
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 > wrote: > > >> On Nov 13, 2016, at 1:38 PM, Андрей Володин via

Re: [swift-evolution] Symmetrical operators

2016-11-13 Thread David Sweeris via swift-evolution
> On Nov 13, 2016, at 1:38 PM, Андрей Володин via swift-evolution > 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: > >

[swift-evolution] Symmetrical operators

2016-11-13 Thread Андрей Володин via swift-evolution
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)