Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 28, 2017, at 8:33 PM, Tony Allevato wrote: > > On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution > wrote: > On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution > wrote: > > >

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: >> > >> > On

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

+1. It seems like a practical first step. > On Nov 28, 2017, at 10:59 AM, Joe Groff via swift-evolution > wrote: > > > >> On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: >> >> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: On

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: > > > > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: > >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu wrote: > > On Tue, Nov 28, 2017 at 00:32 Kelvin Ma wrote: > >> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu wrote: >> >>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: > > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution >>> > wrote: >>> >>> On Nov

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution > wrote: On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

I think this thread derailed quite a bit — it might have even been a good thing that some discussion accidentally went off-list ;-) Personally, I think it's nice if tuples and structs would converge more, so that either struct is seen as an extension of the tuple-concept, or tuple is

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 00:32 Kelvin Ma wrote: > On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu wrote: > >> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma wrote: >> >>> >>> >>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu wrote: > On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma wrote: > >> >> >> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu wrote: >> >>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution > wrote: > > >> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution >> > wrote: >> >> when SE-185 >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> > Ah. You seem to be unfamiliar with protocol existentials. Protocols > (currently, only those without Self or associated type requirements, for > various implementation reasons) are themselves types. For example, you can > write: > A little offtopic, but I've been wanting to ask if it would be

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Why do you need to have this ability to unsafe bitcast? Is interconversion > between point types such a common operation that it's a performance > bottleneck? A real-world example: Real-time image processing. When you have a stream of 4k pictures at 30 fps, you really don’t wont to copy

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> ps i remember that pitch because i’m pretty sure i was the one that pitched > that. No, I was writing about that one: https://www.mail-archive.com/swift-evolution@swift.org/msg30565.html > consensus seemed it was too high level for inclusion (even though having it > at the stdlib level

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 27, 2017, at 1:43 AM, David Hart wrote: > On 27 Nov 2017, at 07:32, John McCall > wrote: > >> >>> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution >>>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 27 Nov 2017, at 07:32, John McCall wrote: > > >>> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution >>> wrote: >>> >>> >>> >>> On 22 Nov 2017, at 07:48, David Hart via swift-evolution >>> wrote:

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution > wrote: > > > >> On 22 Nov 2017, at 07:48, David Hart via swift-evolution >> > wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 25 November 2017 at 23:39, Xiaodi Wu wrote: > On Sat, Nov 25, 2017 at 5:21 PM, Mike Kluev wrote: > >> On 25 November 2017 at 23:07, Xiaodi Wu wrote: >> >>> Not sure what you’re asking. Equatable is a protocol. >>> >> >> that's

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Sat, Nov 25, 2017 at 5:21 PM, Mike Kluev wrote: > On 25 November 2017 at 23:07, Xiaodi Wu wrote: > >> Not sure what you’re asking. Equatable is a protocol. >> > > that's the point. i mean, if user writes this: > > extension (Equatable, Equatable) :

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

on Date: Wed, 22 Nov 2017 08:01:16 +0100 David Hart wrote: > > What confuses me is that I always thought that T? was sugar for > Optional by design, and found that to be quite elegant. ditto, i thought the same. > But now you’re telling me that its just a hack to allow

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 25 November 2017 at 23:07, Xiaodi Wu wrote: > Not sure what you’re asking. Equatable is a protocol. > that's the point. i mean, if user writes this: extension (Equatable, Equatable) : Equatable what *else* could he mean other than this: extension (T, R) : Equatable

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Sat, Nov 25, 2017 at 16:44 Mike Kluev wrote: > On 25 November 2017 at 22:38, Xiaodi Wu wrote: > >> On Sat, Nov 25, 2017 at 4:30 PM, Mike Kluev wrote: >> >>> i haven't encounter this notation before so it looks strange and

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

on Date: Thu, 23 Nov 2017 09:56:35 +1100 Howard Lovatt < howard.lov...@gmail.com> wrote: > > I would defend turning tuples into structs (change from structural type to > nominal type). This is a much better story for programmers, compare the two > stories: > >1. Tuples are just syntax sugar

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 25 November 2017 at 22:38, Xiaodi Wu wrote: > On Sat, Nov 25, 2017 at 4:30 PM, Mike Kluev wrote: > >> >>> i haven't encounter this notation before so it looks strange and >> requires some effort to decipher. if it was e.g. in this form: >> >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Sat, Nov 25, 2017 at 4:30 PM, Mike Kluev wrote: > On 25 November 2017 at 16:04, Xiaodi Wu wrote: > >> >> The workaround substantially bloats the standard library, and the result >> is nothing close to the same because your type is still not

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 25 November 2017 at 16:04, Xiaodi Wu wrote: > > The workaround substantially bloats the standard library, and the result > is nothing close to the same because your type is still not Equatable. This > means that it cannot benefit from any generic algorithms. For example,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 25, 2017, at 08:05, Xiaodi Wu via swift-evolution > wrote: > > >> On Sat, Nov 25, 2017 at 06:35 Mike Kluev wrote: >>> On 25 November 2017 at 03:12, Xiaodi Wu wrote: >> On Fri, Nov 24, 2017 at 9:08 PM, Mike

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Sat, Nov 25, 2017 at 06:35 Mike Kluev wrote: > On 25 November 2017 at 03:12, Xiaodi Wu wrote: > >> On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> On 24 November 2017 at 23:47, Douglas

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 25 November 2017 at 03:12, Xiaodi Wu wrote: > On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution < > swift-evolution@swift.org> wrote: > >> On 24 November 2017 at 23:47, Douglas Gregor wrote: >> >>> >>> e.g., making all tuples of Equatable

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Nov 24, 2017, at 9:20 PM, Douglas Gregor wrote: >> Ok, so you just happened to pick a simple one: > > Yup. Try to make a nominal type to describe labeled tuples. People keep talking about adding integer values to generics, why not strings too? ;-) >> what is the benefit

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Sent from my iPhone > On Nov 24, 2017, at 4:06 PM, Chris Lattner wrote: > >> On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution >> wrote: >> One could imagine adding a “curry” operation to function types: > > Right, having

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Fri, Nov 24, 2017 at 9:08 PM, Mike Kluev via swift-evolution < swift-evolution@swift.org> wrote: > On 24 November 2017 at 23:47, Douglas Gregor wrote: > >> >> e.g., making all tuples of Equatable elements Equatable >> >> > that's already the case.. (all tuples of equatable

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 24 November 2017 at 23:47, Douglas Gregor wrote: > > e.g., making all tuples of Equatable elements Equatable > > that's already the case.. (all tuples of equatable elements are equatable). no? Mike ___ swift-evolution mailing

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution wrote: > One could imagine adding a “curry” operation to function types: Right, having non-nominal types participate in the generics system would be undoubtably awesome! :) > Or perhaps making metatypes

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 22, 2017, at 2:59 PM, Mike Kluev wrote: > > on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor > wrote: > > > On Nov 21, 2017, at 10:48 PM, David Hart > > wrote:

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 6:27 PM, Kelvin Ma wrote: > > > On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu wrote: > >> >> On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> >>> On Thu, Nov 23, 2017 at

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 7:08 PM, Xiaodi Wu wrote: > > On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: >> >>> >>> a good idea on paper, a disastrous

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 16:45 Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote: > > > On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > >> >> a good idea on paper, a disastrous one in practice. What happens if every >> geometry library declares their own Point

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 5:45 PM, Kelvin Ma wrote: > > > On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > >> >> a good idea on paper, a disastrous one in practice. What happens if every >> geometry library declares their own Point type? >> >> That would be

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Thu, Nov 23, 2017 at 12:32 PM, Tino Heth <2...@gmx.de> wrote: > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? > > That would be ugly („disastrous“ imho is a little bit to strong — C++ > had/has similar issues, and

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? That would be ugly („disastrous“ imho is a little bit to strong — C++ had/has similar issues, and other languages as well) But if there would be a simple Point struct in

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

You don't necessarily need variadic generics to enable tuples to be nominal types. Though you do need some changes to the generic type system. One possibility is: struct Tuple_0_Int_1_Int: Collection /*where T0: T, T1: T*/ { // Mangle name. Need covariant generics to enable constraint of T0 and

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution > wrote: > >> On Nov 21, 2017, at 10:48 PM, David Hart wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >> wrote: >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

on Date: Tue, 21 Nov 2017 22:54:21 -0800 Douglas Gregor wrote: > On Nov 21, 2017, at 10:48 PM, David Hart wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution < > swift-evolution@swift.org > wrote: >

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

I would defend turning tuples into structs (change from structural type to nominal type). This is a much better story for programmers, compare the two stories: 1. Tuples are just syntax sugar for simple structs. 2. Tuples are sort of like structs but there is a list of things tuples can

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 22 Nov 2017, at 07:54, Douglas Gregor wrote: > > > >> On Nov 21, 2017, at 10:48 PM, David Hart > > wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 22 Nov 2017, at 07:48, David Hart via swift-evolution > wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > > wrote: > >> >> >>> On Nov 21, 2017, at 10:37 PM, Chris

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 10:48 PM, David Hart wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > > wrote: > >> >> >>> On Nov 21, 2017, at 10:37 PM, Chris Lattner

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 21, 2017, at 10:37 PM, Chris Lattner wrote: >> >> On Nov 21, 2017, at 9:25 PM, Douglas Gregor wrote: Or alternatively, one could

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 10:37 PM, Chris Lattner wrote: > > On Nov 21, 2017, at 9:25 PM, Douglas Gregor > wrote: >>> Or alternatively, one could decide to make the generics system *only and >>> forever* work on nominal types,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Nov 21, 2017, at 9:25 PM, Douglas Gregor wrote: >> Or alternatively, one could decide to make the generics system *only and >> forever* work on nominal types, and make the syntactic sugar just be sugar >> for named types like Swift.Tuple, Function, and Optional. Either

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 22.11.2017 um 06:25 schrieb Douglas Gregor via swift-evolution > : > > > >>> On Nov 21, 2017, at 9:21 PM, Chris Lattner wrote: >>> >>> >>> >>> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 9:21 PM, Chris Lattner wrote: > > > >> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> >> >> Sent from my iPhone >> >> On Nov 21, 2017, at 3:46 PM,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > > On Nov 21, 2017, at 3:46 PM, Tony Allevato > wrote: > >> Does that mean that once structural

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Sent from my iPhone > On Nov 21, 2017, at 3:46 PM, Tony Allevato wrote: > > Does that mean that once structural types can conform to protocols, would the > core team want to remove Optional as a nominal type and just use “T?”? Yes; at least, it’s a direction we’ve

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Does that mean that once structural types can conform to protocols, would the core team want to remove Optional as a nominal type and just use “T?”? Or has that ship sailed because of source compatibility and you just don’t want to introduce any new nominals that shadow structurals? On Tue, Nov

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 3:05 PM, Slava Pestov wrote: > > > >> On Nov 21, 2017, at 6:02 PM, David Hart > > wrote: >> >> Can somebody explain to me what are >> nominal and structural types and why Optional should really be a

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 6:02 PM, David Hart wrote: > > Can somebody explain to me what are > nominal and structural types and why Optional should really be a structural > type? Nominal types are structs, enums, protocols and classes. They have declarations in source and

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 21 Nov 2017, at 22:44, Douglas Gregor wrote: > > > >>> On Nov 20, 2017, at 10:31 PM, Chris Lattner wrote: >>> >>> >>> >>> On Nov 20, 2017, at 10:24 PM, David Hart wrote: >>> >>> >>> >>> On 21 Nov 2017, at 03:17, Chris

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 6:07 PM, Tony Allevato via swift-evolution > wrote: > > This is something I've wanted to look at for a while. A few weeks ago I > pushed out https://github.com/apple/swift/pull/12598 > to extend the

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 6:17 PM, Chris Lattner via swift-evolution > wrote: > > Yes, I agree, we need variadic generics before we can have tuples conform :-( Well, we don’t *have* to have variadic generics to allow structural types to conform… it just composes

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 10:31 PM, Chris Lattner wrote: > > > >> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote: >> >> >> >> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 9:06 AM, David Hart wrote: > >>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>> > wrote: >>> Yes, I agree, we need variadic generics before we can have tuples conform

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 21 Nov 2017, at 07:31, Chris Lattner wrote: > > > >> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote: >> >> >> >> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 21, 2017 at 8:43 AM Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > In Scala they just define Tuple1, Tuple2, ... up to 22 (I think). > Eliminates the need for variadic generics and works fine in practice in > Scala. > > In Swift this approach is possibly

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

In Scala they just define Tuple1, Tuple2, ... up to 22 (I think). Eliminates the need for variadic generics and works fine in practice in Scala. In Swift this approach is possibly unacceptable, since having to write: extension Tuple1 ... extension Tuple2 ... ... extension

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 11:32 PM, Kelvin Ma via swift-evolution > wrote: > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? we’d end up with the same situation we have now where everyone

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 21.11.2017 um 07:32 schrieb Kelvin Ma : > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? Well, if I really had the need to use several geometry libraries at once I would have to convert,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type? On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz wrote: > > > Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution < >

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 10:24 PM, David Hart wrote: > > > > On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution > > wrote: > >> Yes, I agree, we need variadic generics before we can have tuples conform

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution > wrote: > > Yes, I agree, we need variadic generics before we can have tuples conform :-( > > At the end of the day, you want to be able to treat “(U, V, W)” as sugar for > Tuple just like we

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution > : > > when SE-185 went through swift evolution, it was agreed that the next logical > step is synthesizing these conformances for tuple types, though it was left > out of the original proposal to

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Nov 20, 2017, at 6:31 PM, Tony Allevato wrote: > > So (borrowing C++-ish notation), a function of type `(Args...) -> Result` > would become sugar for something like `Function`? That > certainly makes sense. Yep > How would throw-ness be

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Nov 20, 2017, at 6:30 PM, Kelvin Ma via swift-evolution wrote: > > can we go the route of SE-15 and just synthesize up to some sensible n = 7 or > whatever. i feel like this list has a habit of going “but it would be a lot > better to add X if we just wait until

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

So (borrowing C++-ish notation), a function of type `(Args...) -> Result` would become sugar for something like `Function`? That certainly makes sense. How would throw-ness be handled—would we need ThrowingFunction and Function, with the ability to coerce Function ->

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

can we go the route of SE-15 and just synthesize up to some sensible n = 7 or whatever. i feel like this list has a habit of going “but it would be a lot better to add X if we just wait until Y is a thing first” ignoring that Y will probably not be a thing for the forseeable future and we really

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Yes, I agree, we need variadic generics before we can have tuples conform :-( At the end of the day, you want to be able to treat “(U, V, W)” as sugar for Tuple just like we handle array sugar. When that is possible, Tuple is just a type like any other in the system (but we need

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Ignoring synthesized conformances for a second, think about how you would manually implement a conformance of a tuple type to a protocol. You would need some way to statically “iterate” over all the component types of the tuple — in fact this is the same as having variadic generics. If we had

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

This is something I've wanted to look at for a while. A few weeks ago I pushed out https://github.com/apple/swift/pull/12598 to extend the existing synthesis to handle structs/enums when a field/payload has a tuple of things that are Equatable/Hashable, and in that PR it was (rightly) observed, as

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Agree: I think it’s painfully obvious that we want tuples to conform to Equatable under the appropriate circumstances. Whether this is magic or not is not strictly settled (though I agree with Kelvin that magic is sensible here), but right now the issue is that tuples can’t conform to protocols at

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Nov 20, 2017, at 5:48 PM, Kelvin Ma wrote: > the end goal here is to use tuples as a compatible currency type, to that end > it makes sense for these three protocols to be handled as “compiler magic” > and to disallow users from manually defining tuple conformances

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

the end goal here is to use tuples as a compatible currency type, to that end it makes sense for these three protocols to be handled as “compiler magic” and to disallow users from manually defining tuple conformances themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution > wrote: > > when SE-185 > > went through swift evolution, it was agreed that the next logical step