Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-31 Thread L. Mihalkovic via swift-evolution
If Swift is to be used for serious data handling, might as well learn from the java early errors and directly go highly optimized intrinsic code for this type of features: even phones have very good vectorized instructions ... would be tragic to use run of the mill gereral purpose code instead

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-31 Thread Brent Royal-Gordon via swift-evolution
> I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that > automatic conformance can be defined in the language itself and that derived > protocol instances don't have to be implemented as compiler intrinsics. > That's just not the case. You cannot define something like >

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Mark Sands via swift-evolution
In light of Chris and Dave's responses about how this discussion will be mostly absent of core team members until Swift 3 is more or less wrapped up, perhaps we should let this thread sit idle until then. As the original necromancer, I'm sure this will be brought back to life when it's appropria

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Patrick Smith via swift-evolution
Yes exactly, use the protocol conformance syntax, Michael’s description was mistaken I think. Just the same way you get protocol extensions without having to use a special keyword. > On 31 May 2016, at 6:26 AM, Vladimir.S via swift-evolution > wrote: > > I see these two groups: both wants e

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Michael Peternell via swift-evolution
I'm not a fan of AutoEquatable or AutoHashable. These protocols suggest that automatic conformance can be defined in the language itself and that derived protocol instances don't have to be implemented as compiler intrinsics. That's just not the case. You cannot define something like @auto prot

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread David Sweeris via swift-evolution
If you're asking me, it depends on what gets filled in for "syntax". I see no reason to explicitly prohibit classes from participating, though. - Dave Sweeris > On May 30, 2016, at 16:12, Vladimir.S wrote: > > In case we discuss this feature not for just value types but for classes also > - w

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Vladimir.S via swift-evolution
In case we discuss this feature not for just value types but for classes also - will such AutoEquatable allows to implement protocol manually? Now we can have: func == (lhs: A, rhs: A) -> Bool { return true } class A: Hashable { var hashValue: Int { return 100 } } class B: A { override var hash

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Callionica (Swift) via swift-evolution
Is there no one that thinks it's sufficient if users can create a tuple from a list of properties and reuse tuple equality and hash? Is there no one that thinks it's sufficient if the system were to supply a named function for comparing two Any's for equality (with reference equality semantics for

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread David Sweeris via swift-evolution
What about declaring the requirements for auto-conformance in a sub-protocol? @auto protocol AutoEquatable : Equatable { //"syntax" for how to conform to Equatable } struct Foo : AutoEquatable {} //the compiler automatically synthesizes everything struct Bar : Equatable {} //you manually conf

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Chris Lattner via swift-evolution
> On May 30, 2016, at 12:04 PM, Michael Peternell via swift-evolution > wrote: > > It seems that there are two groups here. 1) Group 1 wants Equatable (and > others) be derived automatically unless specifically overridden: similar to > auto-synthesis of properties in Objective-C. 2) The other

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Vladimir.S via swift-evolution
I see these two groups: both wants explicit conformance to protocols, but first thinks that current syntax is enough (`: Equatable`) and second thinks we should introduce new keyword `deriving` for this(`: deriving Equatable`). I see no opinions(except the one opinion in proposal itself) to aut

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread L Mihalkovic via swift-evolution
Seems to me like a heavy weight solution to invent a special keyword that will be applicable to 2 protocols in the entire standard library. If I am not mistaken, the Swift philosophy seems to be that Protocols carry the meaning, not how we apply them. So in this instance, something like the fo

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Michael Peternell via swift-evolution
It seems that there are two groups here. 1) Group 1 wants Equatable (and others) be derived automatically unless specifically overridden: similar to auto-synthesis of properties in Objective-C. 2) The other group (Group 2) wants Equatable (and others) be derived explicitly using a `deriving` key

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread Frank Ecsedy via swift-evolution
In Java I would use Project Lombok's @EqualsAndHashCode annotation on a class. Caveats: 1. Swift is not Java and that's a good thing (TM). 2. Project Lombok is not Java, either. 3. 'deriving Equatable, Hashable' makes those interfaces 'magic'. Is that good?

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread L Mihalkovic via swift-evolution
> On May 29, 2016, at 4:12 PM, Vladimir.S via swift-evolution > wrote: > > On 27.05.2016 18:37, plx via swift-evolution wrote: >> >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> A `deriving` keyword, at the very least, is

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-30 Thread L Mihalkovic via swift-evolution
> On May 29, 2016, at 3:31 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On May 29, 2016, at 8:25 AM, Vladimir.S wrote: >> >> >> Should 'deriving' allows us to manually implement protocol requirements? For >> example >> struct A : deriving Hashable { >>

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Patrick Smith via swift-evolution
Yes, and I’ve been arguing for it being explicit by conforming to the Equatable / Hashable protocol. This would then work the same way as protocol extensions. Protocol extension don’t require a special ‘deriving’ keyword, so I don’t believe there needs to be one here. Just conforming to the prot

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread plx via swift-evolution
> On May 29, 2016, at 9:22 AM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution >> wrote: >> >>> On 27.05.2016 18:37, plx via swift-evolution wrote: >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On May 29, 2016, at 9:12 AM, Vladimir.S via swift-evolution > wrote: > >> On 27.05.2016 18:37, plx via swift-evolution wrote: >> >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> A `deriving` keyword, a

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On May 29, 2016, at 8:41 AM, Vladimir.S via swift-evolution > wrote: > > Saw `class` in examples and want to clarify.. Are we discussing auto-deriving > for *value types only*. Or for classes also? > As I understand, there could be some additional questions/issues for thi

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Vladimir.S via swift-evolution
On 27.05.2016 18:37, plx via swift-evolution wrote: On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution mailto:swift-evolution@swift.org>> wrote: A `deriving` keyword, at the very least, is pretty explicitly *not* an all-or-nothing situation. If you want to define equality/hashability

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Vladimir.S via swift-evolution
Saw `class` in examples and want to clarify.. Are we discussing auto-deriving for *value types only*. Or for classes also? As I understand, there could be some additional questions/issues for this feature because of class inheritance. But probably this feature could be discussed for `final` clas

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On May 29, 2016, at 8:25 AM, Vladimir.S wrote: > > > Should 'deriving' allows us to manually implement protocol requirements? For > example > struct A : deriving Hashable { > var hasValue : Int {...} > } > > Or there should be a compilation error in this case? This sho

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Vladimir.S via swift-evolution
Should 'deriving' allows us to manually implement protocol requirements? For example struct A : deriving Hashable { var hasValue : Int {...} } Or there should be a compilation error in this case? Right now I feel that if we can have auto-deriving by using current syntax for protocol confor

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-29 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On May 29, 2016, at 12:28 AM, Patrick Smith wrote: > > Yeah I don’t see a problem. It’s the same way that protocol extensions just > work. Think of this automatic synthesis as a really flexible protocol > extension: > > extension Hashable where Members : Hashable { > v

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Xiaodi Wu via swift-evolution
I feel like there's some parallels here between the design you're proposing (which is neat) and the discussion that's going on in two other threads about how almost any type can be converted to a String by default. There, we've heard deep dissatisfaction about that facility being invoked unintentio

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread T.J. Usiyan via swift-evolution
It isn't explicit that you are synthesizing code. This is especially true because we can still declare conformance on one declaration/extension and implement in another. You could even conform in another file. This isn't generally good form but it is valid code and it is even, in some cases, somewh

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Jon Shier via swift-evolution
I’m sorry, I was misusing the 80/20 principle there, not making an argument that 80% of all types are trivially Equatable (though I would assert the number types that are trivially Equatable would be far greater than those that are not). I was merely stating that the rare cases in which

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Patrick Smith via swift-evolution
Yeah I don’t see a problem. It’s the same way that protocol extensions just work. Think of this automatic synthesis as a really flexible protocol extension: extension Hashable where Members : Hashable { var hashValue : Int { return self.allMembers.reduce(^) // Or whatever combiner is best

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Xiaodi Wu via swift-evolution
That's quite the assertion you make. What's your evidence that 80% of the time an Equatable type is 'trivially' equatable? In stdlib? Foundation? If you could demonstrate that it's really the case, I'd probably be inclined to support default synthesis of conformance to Equatable. On Sat, May 28, 2

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Jon Shier via swift-evolution
> The problem with this is that it doesn’t differentiate between synthesized > and manual conformance. You won’t get error messages you otherwise would > when you intend to supply manual conformance. It is also less clear to a > reader of the code that the default, compiler synthesized impleme

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Matthew Johnson via swift-evolution
> On May 28, 2016, at 8:43 PM, Pedro Vieira via swift-evolution > wrote: > > I really think this would be a great addition to Swift. Although, I don't see > the need to use a new keyword `deriving` for this feature. > The following would be enough: > > struct Foo: Equatable, Hashable { > ..

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Pedro Vieira via swift-evolution
I really think this would be a great addition to Swift. Although, I don't see the need to use a new keyword `deriving` for this feature. The following would be enough: struct Foo: Equatable, Hashable { ... } It's explicit and it uses features already in the language. With this, the compiler wou

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-28 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On May 27, 2016, at 10:08 PM, Patrick Smith via swift-evolution > wrote: > > A different way of layering could be allowing value types to be composed, > where the outer type inherits the inner member’s properties and methods. > > Let’s say you want only fields ‘contentID

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Patrick Smith via swift-evolution
A different way of layering could be allowing value types to be composed, where the outer type inherits the inner member’s properties and methods. Let’s say you want only fields ‘contentID’ and ‘contentData' to participate in equality and hashing, but not ‘revisionID': struct ContentInfo : Eq

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Matthew Johnson via swift-evolution
> On May 27, 2016, at 5:07 PM, plx via swift-evolution > wrote: > > >> On May 27, 2016, at 3:22 PM, Ricardo Parada via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Inline >> >> >> On May 27, 2016, at 2:52 PM, Matthew Johnson > > wr

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread plx via swift-evolution
> On May 27, 2016, at 3:22 PM, Ricardo Parada via swift-evolution > wrote: > > Inline > > > On May 27, 2016, at 2:52 PM, Matthew Johnson > wrote: > >> >>> On May 27, 2016, at 12:48 PM, Ricardo Parada >> > wrote: >>> >>> >>> W

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Matthew Johnson via swift-evolution
> On May 27, 2016, at 3:22 PM, Ricardo Parada wrote: > > Inline > > > On May 27, 2016, at 2:52 PM, Matthew Johnson > wrote: > >> >>> On May 27, 2016, at 12:48 PM, Ricardo Parada >> > wrote: >>> >>> >>> What if we get the error when tr

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Ricardo Parada via swift-evolution
Inline > On May 27, 2016, at 2:52 PM, Matthew Johnson wrote: > > >> On May 27, 2016, at 12:48 PM, Ricardo Parada wrote: >> >> >> What if we get the error when trying to use it? For example, if a struct >> uses a value that is not Equatable / Hashable then it would not be Equatable >> / H

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread plx via swift-evolution
> On May 27, 2016, at 10:48 AM, Matthew Johnson wrote: > >> >> On May 27, 2016, at 10:37 AM, plx via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> A `

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Matthew Johnson via swift-evolution
> On May 27, 2016, at 12:48 PM, Ricardo Parada wrote: > > > What if we get the error when trying to use it? For example, if a struct > uses a value that is not Equatable / Hashable then it would not be Equatable > / Hashable and you would not find out until you tried to use it. Would that

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Ricardo Parada via swift-evolution
What if we get the error when trying to use it? For example, if a struct uses a value that is not Equatable / Hashable then it would not be Equatable / Hashable and you would not find out until you tried to use it. Would that be bad? > On May 26, 2016, at 11:35 AM, Matthew Johnson via swift

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Patrick Smith via swift-evolution
It would fail if not all members were Equatable or Hashable. If it was automatic, you wouldn’t get any warning or sign at all. If you have to explicitly conform to the protocols, then your intention is clear, and if an automatic implementation cannot be made (because not all members were Equatab

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Matthew Johnson via swift-evolution
> On May 27, 2016, at 10:37 AM, plx via swift-evolution > wrote: > > >> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> A `deriving` keyword, at the very least, is pretty explicitly *not* an >> all-or-nothing situation. If you

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread plx via swift-evolution
> On May 26, 2016, at 1:00 PM, T.J. Usiyan via swift-evolution > wrote: > > A `deriving` keyword, at the very least, is pretty explicitly *not* an > all-or-nothing situation. If you want to define equality/hashability for your > type manually, don't use `deriving`. This should leave the simpl

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Ricardo Parada via swift-evolution
When would the automatic implementation fail? I see your point about adding to the compile size and I had previously mentioned that. Usually in the apps I develop that is not a concern. However I can see it could be a concern for apps that are more restrictive. If Swift is to be used to build s

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Evan Maloney via swift-evolution
I agree. This also isn't the only case where a 'deriving' keyword would come in handy. I'm mulling a proposal for a compiler-derived enum, and I worried the magic-ness of it would face strong opposition. Having a 'deriving' keyword is the perfect solution, since it becomes explicit. > On May

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Patrick Smith via swift-evolution
If you have to specify Equatable / Hashable, then you can get an error if the automatic implementation failed, due to a member also not being Equatable/Hashable. If it’s automatic, then it will just quietly fail, making problems harder to know about and track. It will also always add to the comp

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-27 Thread Ricardo Parada via swift-evolution
I agree, I think there is no need for deriving/synthesizes, but also, no need to specify Equatable, Hashable. They should get the functionality by default but allow for override and customization. > On May 26, 2016, at 11:02 PM, Patrick Smith wrote: > > I don’t understand why you couldn’t co

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread L. Mihalkovic via swift-evolution
Regards (From mobile) > On May 27, 2016, at 6:27 AM, David Sweeris via swift-evolution > wrote: > > +1 for "deriving", "synthesizes", or some other keyword. How are we going to > tell the compiler what protocols can participate? Something like > "@memberwise" is all I can think of, but I'm

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread David Sweeris via swift-evolution
+1 for "deriving", "synthesizes", or some other keyword. How are we going to tell the compiler what protocols can participate? Something like "@memberwise" is all I can think of, but I'm too tired for deep thought at the moment. - Dave Sweeris > On May 26, 2016, at 21:57, Ricardo Parada via swi

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Ricardo Parada via swift-evolution
As Steve Jobs once said when demoing Interface Builder during the NeXT days: "The line of code you don't have to write is the line of code you don't have to debug." P.S. I hope I got the quote right, but that was the idea. :-) Sent from my iPhone > On May 25, 2016, at 10:02 PM, Patrick Sm

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Ricardo Parada via swift-evolution
I like this. I don't see why not make this the default. If someone thinks it is not needed for their application then they simply don't use it. Having it there would not cause any harm. Unless someone had a requirement to have strict control on the size of the application and had to cut d

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Patrick Smith via swift-evolution
I don’t understand why you couldn’t conform to Equatable, and if it fulfils the requirements (all members are also Equatable), then its implementation is automatically created for you. That way you don’t need a new keyword. It’s like Objective-C’s property automatic synthesising that get used un

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Ricardo Parada via swift-evolution
I wonder if synthesizes would be a better choice than deriving. > On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution > wrote: > > Can we just copy&paste the solution from Haskell instead of creating our own? > It's just better in every aspect. Deriving `Equatable` and `Has

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Dave Abrahams via swift-evolution
on Wed May 25 2016, Tony Allevato wrote: > I was inspired to put together a draft proposal based on an older discussion > in > the Universal Equality, Hashability, and Comparability thread > that recently > got necromanced (thanks

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread T.J. Usiyan via swift-evolution
A `deriving` keyword, at the very least, is pretty explicitly *not* an all-or-nothing situation. If you want to define equality/hashability for your type manually, don't use `deriving`. This should leave the simplest cases to auto generation and anything more complex should be handled by the develo

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On May 26, 2016, at 12:20 PM, L. Mihalkovic via swift-evolution > wrote: > > what i care about is to have a choice about what DEFINES the identity of my > values, not just an all-or-nothing situation. I'm sure nobody would object if you offers suggestions. I have some t

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread L. Mihalkovic via swift-evolution
I get this sense that everyone is foxussing on the how, without having clearly defined the what. And this is not the first time I see a lot of great ideas flaring about how to convey a given syntax, without reading a proper definition of the concept. > On May 26, 2016, at 6:15 PM, Michael Pete

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread L. Mihalkovic via swift-evolution
what i care about is to have a choice about what DEFINES the identity of my values, not just an all-or-nothing situation. > On May 26, 2016, at 5:18 PM, T.J. Usiyan via swift-evolution > wrote: > > +1 to a `deriving` keyword > >> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-ev

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Michael Peternell via swift-evolution
> Am 26.05.2016 um 17:35 schrieb Matthew Johnson : > > >> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution >> wrote: >> >> +1 to a `deriving` keyword > > + 1. I like it as well. It makes the feature opt-in, declaring conformance > and requesting synthesis at the same time. T

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Matthew Johnson via swift-evolution
> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution > wrote: > > +1 to a `deriving` keyword + 1. I like it as well. It makes the feature opt-in, declaring conformance and requesting synthesis at the same time. The syntactic difference from a simple conformance declaration mean

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread T.J. Usiyan via swift-evolution
+1 to a `deriving` keyword On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > Can we just copy&paste the solution from Haskell instead of creating our > own? It's just better in every aspect. Deriving `Equatable` and `Hashable` > would bec

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread plx via swift-evolution
I really want synthesized equality (etc.), but having seen the previous discussions on this and related topics I am not sure that directly-deriving the `==` function is the right approach. The main reason I say this is that although this works great for the easy case — all fields equatable, do

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-26 Thread Michael Peternell via swift-evolution
Can we just copy&paste the solution from Haskell instead of creating our own? It's just better in every aspect. Deriving `Equatable` and `Hashable` would become struct Polygon deriving Equatable, Hashable { ... } This has several advantages: - you don't have to guess wether `Equatable` or `

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-25 Thread L. Mihalkovic via swift-evolution
Regards (From mobile) > On May 26, 2016, at 3:46 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On May 25, 2016, at 8:08 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> Omission of fields from generated computations >>> >>> Should it be possibl

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-25 Thread L. Mihalkovic via swift-evolution
On May 26, 2016, at 3:08 AM, Brent Royal-Gordon via swift-evolution wrote: >> Omission of fields from generated computations >> >> Should it be possible to easily omit certain properties from automatically >> generated equality tests or hash value computation? This could be valuable, >> for

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-25 Thread Patrick Smith via swift-evolution
This would be very handy! It’s one of those rare scenarios where I think “I can’t believe Swift makes me type all this out, there must be an easier way”. I think explicitly conformance to Equatable and Hashable would be preferable. This means if one of the members is not Equable/Hashable, the us

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-25 Thread Mark Sands via swift-evolution
Thanks so much for putting this together, Tony! Glad I was able to be some inspiration. :^) On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > I was inspired to put together a draft proposal based on an older > discussion in the Universal Equ

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-25 Thread Matthew Johnson via swift-evolution
Sent from my iPad On May 25, 2016, at 8:08 PM, Brent Royal-Gordon via swift-evolution wrote: >> Omission of fields from generated computations >> >> Should it be possible to easily omit certain properties from automatically >> generated equality tests or hash value computation? This could b

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-25 Thread Brent Royal-Gordon via swift-evolution
> Omission of fields from generated computations > > Should it be possible to easily omit certain properties from automatically > generated equality tests or hash value computation? This could be valuable, > for example, if a property is merely used as an internal cache and does not > actually

[swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

2016-05-25 Thread Tony Allevato via swift-evolution
I was inspired to put together a draft proposal based on an older discussion in the Universal Equality, Hashability, and Comparability thread that recently got necromanced (thanks Mark Sands!). I'm guessing that this would be a signif