Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-16 Thread Jordan Rose via swift-evolution
One additional point that could justify leaving out classes: because classes have reference semantics, it's not always clear that "all members are equal" implies "these instances are equal". Class instances have identity, which may be significant when deciding whether two objects are "the

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-16 Thread Tony Allevato via swift-evolution
Correct, that's not supported yet (it's in the limitations section of the proposal). The first version is very limited in scope to support the common cases, and additional features can be added later if needed. Anything we would add to support omitting properties would likely also apply to

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-16 Thread Xiaodi Wu via swift-evolution
Not in this proposal, unless something has changed. I think it's reasonable for the first iteration of this feature to say that if you want to customize how equality is determined, you write your own `==`. On Tue, May 16, 2017 at 05:56 T.J. Usiyan wrote: > Is there any

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-16 Thread T.J. Usiyan via swift-evolution
Is there any mechanism to mark a property as not participating in derived conformances? One instance might be that I have a memoization/cache related property that is stored but should not be considered when equating two instances. TJ On Tue, May 16, 2017 at 3:51 AM, Xiaodi Wu via

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Xiaodi Wu via swift-evolution
On Mon, May 15, 2017 at 7:18 PM, Tony Allevato wrote: > > > On Mon, May 15, 2017 at 4:38 PM Itai Ferber wrote: > >> On May 15, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> This is nice. Thanks for taking

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Tony Allevato via swift-evolution
On Mon, May 15, 2017 at 4:38 PM Itai Ferber wrote: > On May 15, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > This is nice. Thanks for taking the time to write it up. I do have some > concerns/questions: > > Do the rules you spell

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Tony Allevato via swift-evolution
Just to update everyone on the thread—it took a little longer than I'd hoped to get the kinks out, but I finally have the implementation up as a PR: https://github.com/apple/swift/pull/9619 Hopefully there's still enough time to get the proposal reviewed, make any changes needed, and get this

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Itai Ferber via swift-evolution
> On May 15, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution > wrote: > > This is nice. Thanks for taking the time to write it up. I do have some > concerns/questions: > > Do the rules you spell out align with those for Codable? I think it is very > important that

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Xiaodi Wu via swift-evolution
Oh, and to add, the details of hashing may not need to be fully written out, but it would be nice to mention that it will follow existing standard library practice--or, if not, then why, and also any implications related to hash collision security issues. Moreover, it may be worth mentioning that

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Xiaodi Wu via swift-evolution
This is nice. Thanks for taking the time to write it up. I do have some concerns/questions: Do the rules you spell out align with those for Codable? I think it is very important that these are paralleled as closely as possible, and that any deviations are explicitly called out in the text with

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Tony Allevato via swift-evolution
Yes—the PR of the proposal is here: https://github.com/apple/swift-evolution/pull/706 It needs to be updated slightly—I'll remove the references to the "multiplicative hash function" recommendation because I ended up using the existing _mixInt and xor, which is how the standard library implements

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-15 Thread Andrew Bennett via swift-evolution
Nice work Tony! Is this proposal up for PR on swift-evolution as well? On Tue, 16 May 2017 at 7:30 am, Tony Allevato wrote: > Just to update everyone on the thread—it took a little longer than I'd > hoped to get the kinks out, but I finally have the implementation up as

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-09 Thread Brent Royal-Gordon via swift-evolution
> On May 9, 2017, at 3:53 PM, Tony Allevato via swift-evolution > wrote: > > Likewise, proposing a new public addition to the standard library would > inspire far more design discussion than I believe we have time for if we want > this to make Swift 4. :) Agreed.

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-09 Thread Andrew Bennett via swift-evolution
I suspected that would be the case with the function, thanks for confirming Tony. I agree with Tony that it's not worth slowing down this proposal to get tuples in, although it would be nice if this proposal applied to all value types. Thanks for pursuing this proposal, I have no intention of

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-09 Thread Xiaodi Wu via swift-evolution
On Tue, May 9, 2017 at 5:53 PM, Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > While I agree that it would be nice to handle tuples in those contexts, it > also adds a fair amount of complexity to the implementation of the > synthesis. I imagine that time would be better

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-09 Thread Jose Cheyo Jimenez via swift-evolution
Hi Andrew, Implicitly making Tuples Hashable should be its own proposal. Take a look at the Equable Tuple proposal as a template. https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-09 Thread Tony Allevato via swift-evolution
While I agree that it would be nice to handle tuples in those contexts, it also adds a fair amount of complexity to the implementation of the synthesis. I imagine that time would be better spent just making tuples conform to Equatable/Hashable properly instead of hacking it, because then the

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-09 Thread Andrew Bennett via swift-evolution
Also, when implementing this proposal it's going to be necessary to combine multiple hashes together. It would be awesome if this was done in a reusable way. If it doesn't slow the proposal down it would be awesome if it also introduced a stdlib function: public func combine_hashes(_ elements:

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-09 Thread Andrew Bennett via swift-evolution
You state that you will not synthesise conformance for tuples, I agree with this, but if a struct or enum holds a tuple it would be nice if it could be hashed if its members are all hashable. struct A { var a: Int, b: Int, c: Int } struct B { var tuple: (a: Int, b: Int, c: Int) } I'd

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-08 Thread Matthew Johnson via swift-evolution
> On May 8, 2017, at 4:17 PM, Tony Allevato wrote: > > > > On Mon, May 8, 2017 at 2:11 PM Matthew Johnson > wrote: >> On May 8, 2017, at 4:02 PM, Tony Allevato >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-08 Thread Tony Allevato via swift-evolution
On Mon, May 8, 2017 at 2:11 PM Matthew Johnson wrote: > On May 8, 2017, at 4:02 PM, Tony Allevato wrote: > > On Sat, May 6, 2017 at 4:17 PM Chris Lattner wrote: > >> On May 5, 2017, at 11:33 AM, Tony Allevato via

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-08 Thread Matthew Johnson via swift-evolution
> On May 8, 2017, at 4:02 PM, Tony Allevato wrote: > > On Sat, May 6, 2017 at 4:17 PM Chris Lattner > wrote: > On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-08 Thread Tony Allevato via swift-evolution
On Sat, May 6, 2017 at 4:17 PM Chris Lattner wrote: > On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> >> Can the opt-in conformance be declared in an extension? If so, can the >> extension be in a different

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-08 Thread Matthew Johnson via swift-evolution
> On May 8, 2017, at 3:17 PM, Michael Ilseman via swift-evolution > wrote: > > If an extension on your type declares a hashValue property, what should be > the semantics? Is that an error (conflicts with default provided one), or is > that one used? How does

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-08 Thread Michael Ilseman via swift-evolution
If an extension on your type declares a hashValue property, what should be the semantics? Is that an error (conflicts with default provided one), or is that one used? > On May 4, 2017, at 3:20 PM, Andrew Bennett via swift-evolution > wrote: > > That's correct,

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-06 Thread Chris Lattner via swift-evolution
On May 5, 2017, at 11:33 AM, Tony Allevato via swift-evolution wrote: > > > > Can the opt-in conformance be declared in an extension? If so, can the > extension be in a different module than the original declaration? If so, do > you intend any restrictions, such

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-06 Thread Chris Lattner via swift-evolution
> On May 4, 2017, at 3:01 PM, Xiaodi Wu via swift-evolution > wrote: > > Hmm, I can see the appeal of automatically deriving Equatable and Hashable > conformance, but I'd like that to be opt-in. That is, types should declare > that they are Equatable or Hashable to

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Xiaodi Wu via swift-evolution
It would have to be compiler magic. If I recall, the only factor preventing it is that no one has implemented it, but one of the core team members has noted that it should be fairly straightforward. I don't have the time right now or I'd seriously take a stab at it. On Fri, May 5, 2017 at 14:20

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Tony Allevato via swift-evolution
On Fri, May 5, 2017 at 12:18 PM Xiaodi Wu wrote: > Hmm, with these complications, I regret suggesting that this could be > extended to classes so easily. Definitely some interesting solutions, but > my inclination as well would be to leave classes out entirely for the >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Xiaodi Wu via swift-evolution
Hmm, with these complications, I regret suggesting that this could be extended to classes so easily. Definitely some interesting solutions, but my inclination as well would be to leave classes out entirely for the moment and let it percolate for Swift 4.1+. After all, it's an additive convenience.

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Matthew Johnson via swift-evolution
> On May 5, 2017, at 2:16 PM, Tony Allevato wrote: > > On Fri, May 5, 2017 at 11:51 AM Matthew Johnson > wrote: >> On May 5, 2017, at 1:33 PM, Tony Allevato >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Tony Allevato via swift-evolution
On Fri, May 5, 2017 at 11:51 AM Matthew Johnson wrote: > On May 5, 2017, at 1:33 PM, Tony Allevato wrote: > > > > On Fri, May 5, 2017 at 11:07 AM Matthew Johnson > wrote: > >> On May 5, 2017, at 10:45 AM, Tony Allevato

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Matthew Johnson via swift-evolution
> On May 5, 2017, at 1:33 PM, Tony Allevato wrote: > > > > On Fri, May 5, 2017 at 11:07 AM Matthew Johnson > wrote: >> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution >>

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Tony Allevato via swift-evolution
On Fri, May 5, 2017 at 11:07 AM Matthew Johnson wrote: > On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution < > swift-evolution@swift.org> wrote: > > Thanks for your feedback, everybody! > > > Thanks for continuing to drive this forward! > > > I've updated the

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Matthew Johnson via swift-evolution
> On May 5, 2017, at 10:45 AM, Tony Allevato via swift-evolution > wrote: > > Thanks for your feedback, everybody! Thanks for continuing to drive this forward! > > I've updated the gist > to >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Tony Allevato via swift-evolution
Thanks for your feedback, everybody! I've updated the gist to reflect what seems to be a consensus here: * Derived conformances are now opt-in (this makes the recursive case *much* cleaner, and the complexity involved in that

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-05 Thread Nevin Brackett-Rozinsky via swift-evolution
On Fri, May 5, 2017 at 1:47 AM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Fri, May 5, 2017 at 12:41 AM, Brent Royal-Gordon < > br...@architechies.com> wrote: > >> I would think only final classes could participate in this, since a >> subclassable class would need to

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Brent Royal-Gordon via swift-evolution
> On May 4, 2017, at 3:01 PM, Xiaodi Wu via swift-evolution > wrote: > > Hmm, I can see the appeal of automatically deriving Equatable and Hashable > conformance, but I'd like that to be opt-in. That is, types should declare > that they are Equatable or Hashable to

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Xiaodi Wu via swift-evolution
I see. You're not suggesting magic. The problem stands that the design of Equatable explicitly encourages the distinction between identity and equality (it even says: "equality is separate from identity"). It follows that we should *not* provide a default implementation that forwards one to the

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Charlie Monroe via swift-evolution
> On May 5, 2017, at 6:58 AM, Xiaodi Wu wrote: > > As the documentation for Equatable discusses, the goal is to distinguish > "equality" (==) from "identity" (===). If I understand it correctly, the goal > is to *discourage* mixing the two concepts. > > Moreover, while

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Xiaodi Wu via swift-evolution
As the documentation for Equatable discusses, the goal is to distinguish "equality" (==) from "identity" (===). If I understand it correctly, the goal is to *discourage* mixing the two concepts. Moreover, while writing a memberwise comparison is tedious and writing a memberwise hash is even

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Matthew Johnson via swift-evolution
> On May 4, 2017, at 5:23 PM, Tony Allevato via swift-evolution > wrote: > > When I initially wrote an earlier version of this proposal last year, I was > imagining implicit derivation (as it is today for no-associated-value enums). > However, now that I'm deeper

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Tony Allevato via swift-evolution
When I initially wrote an earlier version of this proposal last year, I was imagining implicit derivation (as it is today for no-associated-value enums). However, now that I'm deeper into it (and have tried implementing some of it), I think explicit is the way to go. My main reason for changing

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Andrew Bennett via swift-evolution
That's correct, consistent with Encoding/Decoding (SE-0166 ) it is sufficient to just do this: struct MyType: Hashable { var foo: Int var bar: Float } Now MyType should get a generated

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Xiaodi Wu via swift-evolution
I should add, requiring opt-in doesn't necessarily mean one must break source compatibility for enums currently with derived equality. That can be grandfathered in. Later, we can even explore more comprehensive functionality when an enum is declared "Foo : Int". In my opinion, the ideal endpoint

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Xiaodi Wu via swift-evolution
I'm imagining no syntax; effectively, as though there exists an "extension Equatable where [ all members : Equatable ]" with a default implementation. On Thu, May 4, 2017 at 17:13 John McCall wrote: > On May 4, 2017, at 6:10 PM, Andrew Bennett via swift-evolution < >

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Andrew Bennett via swift-evolution
I agree, let's make it opt-in. This looks really great, I'm excited to get generated conformance for Equatable/Hashable in time for Swift 4. I think it's worth mentioning that Encoding/Decoding generated conformance is already accepted and implemented in Swift 4. The implementation and

Re: [swift-evolution] Pitch: Automatically deriving Equatable/Hashable for more value types

2017-05-04 Thread Xiaodi Wu via swift-evolution
Hmm, I can see the appeal of automatically deriving Equatable and Hashable conformance, but I'd like that to be opt-in. That is, types should declare that they are Equatable or Hashable to begin with. It wouldn't have to take extra syntax, as compiler magic could effectively synthesize default