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: > > > > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: > > > > On 27.11.2017 20:28,

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 27.11.2017 20:28, Jo

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 Nov 20, 2017, at 5:43 PM, Chris Lattner via swif

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 swift-evolution < > sw

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 wrote: >>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu wrote: >

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolu

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 > wrote: when SE-185

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 considered

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 wrote: >>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift wrote: >

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 wrote: >>> they use packed buffers of floats, which for type safety are bett

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 >> mailto:swift-evolution@swift.org>> 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 buffer

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 would

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> On 22 Nov 2017, at 07:48, David Ha

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: >>> >>> >>> >>> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evoluti

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.o

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 the point. i mean, if user writes this: >> >> extension (Equatabl

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) : Equatable > > what *else* could he mean othe

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 conformance on > Option

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 and if it is indeed th

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 >>> 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 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 fo

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: >> >> extension (Equatable...) : Equatable >> >> then it

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 Equatable. This >> means that it cannot benefit from

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, an > array of such tup

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 Kluev via swift-evolution wrote: >>> > On 24 November 2017

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 Gregor wrote: >>> e.g., making all

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 elements Equatable >>> >>> >> that's alr

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 of plumbing knowledg

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 non-nominal types participate in the generics system wo

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 elements are > equat

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 list swift-evolution@sw

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 Hashable so they can be use

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: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolu

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 12:32 PM, Tino Heth <2...@gmx.de> wrote: >>>

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 one in practice. What h

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 type

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 ugly („disastrous“ imho

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 o

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

> Am 23.11.2017 um 01:50 schrieb David Sweeris via swift-evolution > : > > > 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

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 T1

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: >> >>> >>> On Nov 21, 2017, at 10:37 PM, Chris Lattner 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: > > > >> > >> I think it’s straightforwar

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 d

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Nov 21, 2017

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 > mailto:swift-evolution@swift.org>> wrote: > >> >> >>> On Nov 21, 2017, at 10:37 PM, Chris Lattner >> > wrote: >>> >>> On

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 > mailto:swift-evolution@swift.org>> wrote: > >> >> >>> On Nov 21, 2017, at 10:37 PM, Chris Lattner >> > wrote: >>> >>> On Nov 21, 2017, at 9

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 decide to make the generics system *only and forever* work on

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, and make the syntactic sugar just be sugar

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 design >> could work.

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 >>> wrote: >>> >>> >>> >>> Sent from my iPhone >>> On Nov 21, 2017

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPhone >> >> On Nov 21, 2017, at 3:46 PM, Tony Allevato > > w

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 types can conform to protocols, would >> the core team w

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 discussed a number of times

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 21

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 structural >> type? > > Nominal types are

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 are uniquely identifi

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 Lattner via swift-evolution >>> wrote: >>> Yes, I agre

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 existing synthesis > to ha

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 really, really elegantly. One cou

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> Yes, I agree, we need va

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> Yes, I agree, we need variadic generics before we can have tuples conform :-( At the end of the day, you wa

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> Yes, I agree, we need variad

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 unacce

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 Tuple2

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 declares their own Result typ

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, of course. But I prefe

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 < > swift-evolution@swift.org>: > > when SE-185 >

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 > mailto:swift-evolution@swift.org>> wrote: > >> Yes, I agree, we need variadic generics before we can have tuples conform :-( >> >> At the end of the day, you want to be a

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 handle array sugar. When that is pos

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 avoid mission creep. I think now

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 handled—would we need ThrowingFunction and Function,

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 Y is a thing first” ignoring

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 -> ThrowingFunction? (Async might

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 ne

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 variadics to ex

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 v

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 themselves. > i’m not a fa

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 Comparab

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 >