Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 19, 2017, at 3:29 PM, Haravikk via swift-evolution > wrote: > >> On 19 Aug 2017, at 19:46, Daryle Walker > > wrote: >> >>> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution >>>

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

Chris Lattner wrote: > Also, if I were to nitpick your argument a bit, it isn’t true that the > protocol knows “nothing" about the type anyway, because the protocol has > access to self. The default implementation could conceptually use reflection > to access all the state in the type: we’re

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

On Sat, Aug 19, 2017 at 3:26 PM, Goffredo Marocchi wrote: > Sorry, I thought that the default implementation in the protocol extension > was how this was provided. > > Providing Default Implementations > > You can use protocol extensions to provide a default implementation to

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

Sorry, I thought that the default implementation in the protocol extension was how this was provided. > Providing Default Implementations > You can use protocol extensions to provide a default implementation to any > method or computed property requirement of that protocol >

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 19 Aug 2017, at 19:46, Daryle Walker wrote: > >> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution >> > wrote: >> >>> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de > >>> wrote:

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution > wrote: > >> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de > wrote: >>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution >>>

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

On Sat, Aug 19, 2017 at 1:13 PM, Goffredo Marocchi wrote: > We can override the protocol default implementation in the extension, but > the issue I see with default implementation in Swift is that if I pass the > object created this way around in a type erased container (Any :

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

We can override the protocol default implementation in the extension, but the issue I see with default implementation in Swift is that if I pass the object created this way around in a type erased container (Any : Protocol1 like it was common for many to pass id around in the Objective-C

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote: > > Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution < > swift-evolution@swift.org>: > > For me the whole point of a basic

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote: >> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution >> >: >> For me the whole point of a basic protocol is that it forces me to implement >> some requirements in

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution > : > > For me the whole point of a basic protocol is that it forces me to implement > some requirements in order to conform; I can throw a bunch of protocols onto > a type and know that it won't compile

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 17 Aug 2017, at 18:04, Chris Lattner wrote: >> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution >> > wrote: >>> On 17 Aug 2017, at 11:42, Robert Bennett >>

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution > wrote: > > >> On 17 Aug 2017, at 11:42, Robert Bennett > > wrote: >> >> Chris mentions that the intent was to mimic a default implementation in a

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 17 Aug 2017, at 11:42, Robert Bennett wrote: > > Chris mentions that the intent was to mimic a default implementation in a > constrained protocol extension, with one extension per type that doesn’t > define its own ==/hashValue while conforming to

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

Chris mentions that the intent was to mimic a default implementation in a constrained protocol extension, with one extension per type that doesn’t define its own ==/hashValue while conforming to Equatable/Hashable. Constrained extensions are allowed to use type information from the constraint,

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 17 Aug 2017, at 00:06, Robert Bennett via swift-evolution > wrote: > > How do unstable hash values play with Codable? If you encode and save a Set, > might you have problems interacting with it in the future? (This is more a > Codable question than Hashable,

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

So the concern is that you have a Set of values with derived hashes, it gets encoded, and then a later run of the program decodes that payload, the hash values are different and performance suffers because collisions occur where they previously didn't? (Correctness would never be an issue, since

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

If I understand the question correctly, Robert's asking whether the possibility that hashes might differ on every execution would causes issues if, upon deserializing, one stumbles upon a hash collision which did not occur with the original hashes. And I suppose the answer to that is...yes? On

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

>From what I can tell the hash values of elements in a Set don't come into play during encoding/decoding: they're merely serialized as the sequence of their elements. https://github.com/apple/swift/blob/2e5817ebe15b8c2fc2459e08c1d462053cbb9a99/stdlib/public/core/Codable.swift#L4073-L4097 On Wed,

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

How do unstable hash values play with Codable? If you encode and save a Set, might you have problems interacting with it in the future? (This is more a Codable question than Hashable, but I figure I might as well ask here) > On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution >

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution > wrote: > > That's great. Thanks! Yes, excellent news! I am *really* looking forward to seeing this proposal make it into an Xcode release! > > R+ > > On 17 Aug 2017, at 00:46, John McCall

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution > wrote: > > This is fantastic news! Any chance of this landing in Swift 4.x instead of 5? It it likely to be available in 4.1, but not 4.0. John. > > R+ > >> On 17 Aug 2017, at 00:29, Chris

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

This is fantastic news! Any chance of this landing in Swift 4.x instead of 5? R+ > On 17 Aug 2017, at 00:29, Chris Lattner via swift-evolution > wrote: > > Proposal Link: >