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

[Daryle Walker via swift-evolution]

> 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 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Agreed. To be clear though; in spite of my pessimism this is a feature that 
>>> I do want, but I would rather not have it at all than have it implemented 
>>> in a way that hides bugs and sets a horrible precedent for the future.
>> 
>> I tried to make a split thread for this, but would you object to synthesized 
>> conformance if we had to explicitly add a command within the definition 
>> block to trigger the synthesis? If we add strong type-aliases, we could 
>> reuse the directive to copy an interface (method, inner type, property, or 
>> conformed-to protocol) from the underlying type to the current type for 
>> synthesis too. The only problem would be backward compatibility; once added, 
>> we would urge users to explicitly list “publish Equatable” for synthesis, 
>> but what about code that already uses the implicit version (since this 
>> feature will probably be released for at least one Swift version by the time 
>> strong type-aliases happen), do we force users to change their code?
> 
> I would rather no code at all use the implicit version; one of my points is 
> that it's not something that's easily changed after the fact, which is why it 
> needs to be done correctly now.
> 
> I'm open to any method that makes opting in to the synthesised conformance 
> explicit; I still think a specifically named protocol is the simplest, but 
> I'm not married to that as a solution; attributes, keywords etc. are all fine 
> too, whatever is the easiest way to opt-in to the behaviour explicitly 
> without ambiguity. I'm not 100% sure exactly what you mean by "add a command 
> within the definition block", or is an attribute/keyword what you meant?

The syntax to copy an interface from an underlying type to one of its strong 
type-aliases is a new directive within the definition block:

alter MyInt16: Int16, Hashable {
publish Equatable  // Automatically copies definitions from Int16 needed to 
conform to Equatable
var hashValue: Int { /*…*/ }  // A protocol can be completed with a mix of 
published and direct definitions
}

Since we would be introducing an explicit way to declare implementation of a 
conformance (the “publish” directive), we could reuse the directive for 
Equatable/Hashable/Encodable/Decodable definitions in non-strong-aliases and 
make the current implicit definitions obsolete. The problem then would be 
backwards compatibility; could we force users to go from implicit to explicit 
synthesized conformance?

The original point of publishing is to selectively control which parts of the 
underlying type’s interface get copied. Automatically synthesized conformance, 
if it stays after strong type-aliases are introduced, would screw with that 
(unless synthesized conformance is ignored for strong type-aliases; i.e. our 
conformance exception gets a counter exception).

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Ungar via swift-evolution]

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 producing the same effect with 
> more efficient code.

I had to go back to first principles because it seems to violate the separation 
of reflection and base-level that has been a keystone of the mirrors I invented 
for Self. (When Gilad & I wrote our paper on this, he called this separation 
the principle of "stratification.") So, I thought about why I believed in that 
separation in the first place. I think the key thought was to insulate clients 
of an abstraction from changes in its implementation. 

I went back to the proposal and realized that it ensured such insulation by 
excluding extensions:

> Requirements will be synthesized only for protocol conformances that are part 
> of the type declaration itself; conformances added in extensions will not be 
> synthesized.

Also, the exclusion of classes avoids problems with inheritance.

Bottom line: The proposal won't create problems arising from coupling clients 
to implementations. The restrictions are crucial. When this new feature is 
documented (in the Swift book?), this decoupling might be helpful to motivate 
the restrictions.

- David
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 any
> method or computed property requirement of that protocol
>
> https://developer.apple.com/library/content/documentation/
> Swift/Conceptual/Swift_Programming_Language/Protocols.html#//apple_ref/
> doc/uid/TP40014097-CH25-ID521
>


There are default implementations and extension methods. Both are written
inside protocol extensions. Default implementations are dynamically
dispatched, but extension methods are not. A default implementation
implements a protocol requirement. An extension method adds a method to a
protocol which is not a requirement.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

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
> 

https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html#//apple_ref/doc/uid/TP40014097-CH25-ID521

Sent from my iPhone

>> On 19 Aug 2017, at 19:28, Xiaodi Wu  wrote:
>> 
>> 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 : Protocol1   
>> like it was common for many to pass id around in the Objective-C 
>> days, a good practice IMHO) then my overrode would not be called, but the 
>> default implementation will be used instead. I would be far more comfortable 
>> with this “magic” provided for free of default implementations were 
>> dynamically dispatched.
> 
> Are you referring to protocol extension methods? Those are not default 
> implementations, do not have a corresponding protocol requirement that can be 
> overridden, and are not what's being discussed here.
> 
> 
>> Sent from my iPhone
>> 
 On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution 
  wrote:
 
 
 On Sat, Aug 19, 2017 at 06:07 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 
>> :
>> 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 until I've finished 
>> it, developers get distracted, leave things unfinished to go back to 
>> later, make typos etc. etc. To me declaring a conformance is a 
>> declaration of "my type will meet the requirements for this make, sure I 
>> do it", not "please, please use some magic to do this for me"; there 
>> needs to be a clear difference between the two.
> 
> My conclusion isn't as pessimistic as yours, but I share your objections: 
> Mixing a normal feature (protocols) with compiler magic doesn't feel 
> right to me — wether it's Equatable, Hashable, Codable or Error.
> It's two different concepts with a shared name*, so I think even 
> AutoEquatable wouldn't be the right solution, and something like 
> #Equatable would be a much better indicator for what is happening.
> 
> Besides that specific concern, I can't fight the feeling that the 
> evolution process doesn't work well for proposals like this:
> It's a feature that many people just want to have as soon as possible, 
> and concerns regarding the long-term effects are more or less washed away 
> with eagerness.
> 
> - Tino
> 
> * for the same reason, I have big concerns whenever someone proposes to 
> blur the line between tuples and arrays
 
 Agreed. To be clear though; in spite of my pessimism this is a feature 
 that I do want, but I would rather not have it at all than have it 
 implemented in a way that hides bugs and sets a horrible precedent for the 
 future.
>>> 
>>> This was already touched upon during review, but to reiterate, the analogy 
>>> to default protocol implementations is meant specifically to address this 
>>> point about "hiding bugs." Yes, this feature cannot currently be 
>>> implemented as a default protocol implementation without magic; with better 
>>> reflection facilities there's a good chance that one day it might be, but 
>>> that's not the reason why it's being compared to default protocol 
>>> implementations. The reason for the comparison is that this feature only 
>>> "hides bugs" like a default protocol implementation "hides bugs" (in the 
>>> I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore
>>>  sense of "hiding bugs"), and the addition of default protocol 
>>> implementations, unless I'm mistaken, isn't even considered an API change 
>>> that requires Swift Evolution review.
>>> 
>>> Given Swift's emphasis on progressive disclosure, I'm fairly confident that 
>>> once reflection facilities and/or code-generation facilities improve, many 
>>> boilerplate-y protocol requirements will be given default implementations 
>>> where they cannot be written today. With every advance in expressiveness, 
>>> more protocol requirements that cannot currently have a default 
>>> implementation will naturally acquire them. Since the degree to which the 
>>> compiler will cease to give errors about non-implementation is directly in 
>>> proportion to the boilerplate reduced, it's not a defect

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

[Haravikk via swift-evolution]

> On 19 Aug 2017, at 19:46, Daryle Walker  wrote:
> 
>> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution 
>> mailto: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 
 mailto:swift-evolution@swift.org>>:
 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 until I've finished 
 it, developers get distracted, leave things unfinished to go back to 
 later, make typos etc. etc. To me declaring a conformance is a declaration 
 of "my type will meet the requirements for this make, sure I do it", not 
 "please, please use some magic to do this for me"; there needs to be a 
 clear difference between the two.
>>> 
>>> My conclusion isn't as pessimistic as yours, but I share your objections: 
>>> Mixing a normal feature (protocols) with compiler magic doesn't feel right 
>>> to me — wether it's Equatable, Hashable, Codable or Error.
>>> It's two different concepts with a shared name*, so I think even 
>>> AutoEquatable wouldn't be the right solution, and something like #Equatable 
>>> would be a much better indicator for what is happening.
>>> 
>>> Besides that specific concern, I can't fight the feeling that the evolution 
>>> process doesn't work well for proposals like this:
>>> It's a feature that many people just want to have as soon as possible, and 
>>> concerns regarding the long-term effects are more or less washed away with 
>>> eagerness.
>>> 
>>> - Tino
>>> 
>>> * for the same reason, I have big concerns whenever someone proposes to 
>>> blur the line between tuples and arrays
>> 
>> Agreed. To be clear though; in spite of my pessimism this is a feature that 
>> I do want, but I would rather not have it at all than have it implemented in 
>> a way that hides bugs and sets a horrible precedent for the future.
> 
> I tried to make a split thread for this, but would you object to synthesized 
> conformance if we had to explicitly add a command within the definition block 
> to trigger the synthesis? If we add strong type-aliases, we could reuse the 
> directive to copy an interface (method, inner type, property, or conformed-to 
> protocol) from the underlying type to the current type for synthesis too. The 
> only problem would be backward compatibility; once added, we would urge users 
> to explicitly list “publish Equatable” for synthesis, but what about code 
> that already uses the implicit version (since this feature will probably be 
> released for at least one Swift version by the time strong type-aliases 
> happen), do we force users to change their code?

I would rather no code at all use the implicit version; one of my points is 
that it's not something that's easily changed after the fact, which is why it 
needs to be done correctly now.

I'm open to any method that makes opting in to the synthesised conformance 
explicit; I still think a specifically named protocol is the simplest, but I'm 
not married to that as a solution; attributes, keywords etc. are all fine too, 
whatever is the easiest way to opt-in to the behaviour explicitly without 
ambiguity. I'm not 100% sure exactly what you mean by "add a command within the 
definition block", or is an attribute/keyword what you meant?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daryle Walker via swift-evolution]

> 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 
>>> mailto:swift-evolution@swift.org>>:
>>> 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 until I've finished 
>>> it, developers get distracted, leave things unfinished to go back to later, 
>>> make typos etc. etc. To me declaring a conformance is a declaration of "my 
>>> type will meet the requirements for this make, sure I do it", not "please, 
>>> please use some magic to do this for me"; there needs to be a clear 
>>> difference between the two.
>> 
>> My conclusion isn't as pessimistic as yours, but I share your objections: 
>> Mixing a normal feature (protocols) with compiler magic doesn't feel right 
>> to me — wether it's Equatable, Hashable, Codable or Error.
>> It's two different concepts with a shared name*, so I think even 
>> AutoEquatable wouldn't be the right solution, and something like #Equatable 
>> would be a much better indicator for what is happening.
>> 
>> Besides that specific concern, I can't fight the feeling that the evolution 
>> process doesn't work well for proposals like this:
>> It's a feature that many people just want to have as soon as possible, and 
>> concerns regarding the long-term effects are more or less washed away with 
>> eagerness.
>> 
>> - Tino
>> 
>> * for the same reason, I have big concerns whenever someone proposes to blur 
>> the line between tuples and arrays
> 
> Agreed. To be clear though; in spite of my pessimism this is a feature that I 
> do want, but I would rather not have it at all than have it implemented in a 
> way that hides bugs and sets a horrible precedent for the future.

I tried to make a split thread for this, but would you object to synthesized 
conformance if we had to explicitly add a command within the definition block 
to trigger the synthesis? If we add strong type-aliases, we could reuse the 
directive to copy an interface (method, inner type, property, or conformed-to 
protocol) from the underlying type to the current type for synthesis too. The 
only problem would be backward compatibility; once added, we would urge users 
to explicitly list “publish Equatable” for synthesis, but what about code that 
already uses the implicit version (since this feature will probably be released 
for at least one Swift version by the time strong type-aliases happen), do we 
force users to change their code?

> I realise I may seem to be overreacting, but I really do feel that strongly 
> about what I fully believe is a mistake. I understand people's enthusiasm for 
> the feature, I do; I hate boilerplate as much as the next developer, but as 
> you say, it's not a reason to rush forward, especially when this is not 
> something that can be easily changed later.
> 
> That's a big part of the problem; the decisions here are not just about 
> trimming boilerplate for Equatable/Hashable, it's also about the potential 
> overreach of every synthesised feature now and in the future as well.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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 : Protocol1
>   like it was common for many to pass id around in the
> Objective-C days, a good practice IMHO) then my overrode would not be
> called, but the default implementation will be used instead. I would be far
> more comfortable with this “magic” provided for free of default
> implementations were dynamically dispatched.
>

Are you referring to protocol extension methods? Those are not default
implementations, do not have a corresponding protocol requirement that can
be overridden, and are not what's being discussed here.


Sent from my iPhone
>
> On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> 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 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 until I've finished
>> it, developers get distracted, leave things unfinished to go back to later,
>> make typos etc. etc. To me declaring a conformance is a declaration of "my
>> type will meet the requirements for this make, sure I do it", not "please,
>> please use some magic to do this for me"; there needs to be a clear
>> difference between the two.
>>
>>
>> My conclusion isn't as pessimistic as yours, but I share your objections:
>> Mixing a normal feature (protocols) with compiler magic doesn't feel right
>> to me — wether it's Equatable, Hashable, Codable or Error.
>> It's two different concepts with a shared name*, so I think even
>> AutoEquatable wouldn't be the right solution, and something like #Equatable
>> would be a much better indicator for what is happening.
>>
>> Besides that specific concern, I can't fight the feeling that the
>> evolution process doesn't work well for proposals like this:
>> It's a feature that many people just want to have as soon as possible,
>> and concerns regarding the long-term effects are more or less washed away
>> with eagerness.
>>
>> - Tino
>>
>> * for the same reason, I have big concerns whenever someone proposes to
>> blur the line between tuples and arrays
>>
>>
>> Agreed. To be clear though; in spite of my pessimism this *is* a feature
>> that I *do* want, but I would rather not have it at all than have it
>> implemented in a way that hides bugs and sets a horrible precedent for the
>> future.
>>
>
> This was already touched upon during review, but to reiterate, the analogy
> to default protocol implementations is meant specifically to address this
> point about "hiding bugs." Yes, this feature cannot currently be
> implemented as a default protocol implementation without magic; with better
> reflection facilities there's a good chance that one day it might be, but
> that's not the reason why it's being compared to default protocol
> implementations. The reason for the comparison is that this feature only
> "hides bugs" like a default protocol implementation "hides bugs" (in the
> I-conformed-my-type-and-forgot-to-override-the-
> default-and-the-compiler-won't-remind-me-anymore sense of "hiding bugs"),
> and the addition of default protocol implementations, unless I'm mistaken,
> isn't even considered an API change that requires Swift Evolution review.
>
> Given Swift's emphasis on progressive disclosure, I'm fairly confident
> that once reflection facilities and/or code-generation facilities improve,
> many boilerplate-y protocol requirements will be given default
> implementations where they cannot be written today. With every advance in
> expressiveness, more protocol requirements that cannot currently have a
> default implementation will naturally acquire them. Since the degree to
> which the compiler will cease to give errors about non-implementation is
> directly in proportion to the boilerplate reduced, it's not a defect but a
> feature that these compiler errors go away. At the moment, it is a great
> idea to enable some of these improvements for specific common use cases
> before the general facilites for reflection and/or code-generation are
> improved in later versions of Swift, since the user experience would be
> expected to remain the same once those full facilities arrive.
>
> I realise I may seem to be overreacting, but I really do feel that
>> strongly about what I fully believe is a mistake. I understand people's
>> enthusiasm for the feature, I do; I hate boilerplate as much as the next
>> developer, but as you say, it's not a reason to rush forward, especia

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

[Goffredo Marocchi via swift-evolution]

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 days, a good 
practice IMHO) then my overrode would not be called, but the default 
implementation will be used instead. I would be far more comfortable with this 
“magic” provided for free of default implementations were dynamically 
dispatched.

Sent from my iPhone

> On 19 Aug 2017, at 19:06, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> 
>> On Sat, Aug 19, 2017 at 06:07 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 
 :
 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 until I've finished 
 it, developers get distracted, leave things unfinished to go back to 
 later, make typos etc. etc. To me declaring a conformance is a declaration 
 of "my type will meet the requirements for this make, sure I do it", not 
 "please, please use some magic to do this for me"; there needs to be a 
 clear difference between the two.
>>> 
>>> My conclusion isn't as pessimistic as yours, but I share your objections: 
>>> Mixing a normal feature (protocols) with compiler magic doesn't feel right 
>>> to me — wether it's Equatable, Hashable, Codable or Error.
>>> It's two different concepts with a shared name*, so I think even 
>>> AutoEquatable wouldn't be the right solution, and something like #Equatable 
>>> would be a much better indicator for what is happening.
>>> 
>>> Besides that specific concern, I can't fight the feeling that the evolution 
>>> process doesn't work well for proposals like this:
>>> It's a feature that many people just want to have as soon as possible, and 
>>> concerns regarding the long-term effects are more or less washed away with 
>>> eagerness.
>>> 
>>> - Tino
>>> 
>>> * for the same reason, I have big concerns whenever someone proposes to 
>>> blur the line between tuples and arrays
>> 
>> Agreed. To be clear though; in spite of my pessimism this is a feature that 
>> I do want, but I would rather not have it at all than have it implemented in 
>> a way that hides bugs and sets a horrible precedent for the future.
> 
> This was already touched upon during review, but to reiterate, the analogy to 
> default protocol implementations is meant specifically to address this point 
> about "hiding bugs." Yes, this feature cannot currently be implemented as a 
> default protocol implementation without magic; with better reflection 
> facilities there's a good chance that one day it might be, but that's not the 
> reason why it's being compared to default protocol implementations. The 
> reason for the comparison is that this feature only "hides bugs" like a 
> default protocol implementation "hides bugs" (in the 
> I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore
>  sense of "hiding bugs"), and the addition of default protocol 
> implementations, unless I'm mistaken, isn't even considered an API change 
> that requires Swift Evolution review.
> 
> Given Swift's emphasis on progressive disclosure, I'm fairly confident that 
> once reflection facilities and/or code-generation facilities improve, many 
> boilerplate-y protocol requirements will be given default implementations 
> where they cannot be written today. With every advance in expressiveness, 
> more protocol requirements that cannot currently have a default 
> implementation will naturally acquire them. Since the degree to which the 
> compiler will cease to give errors about non-implementation is directly in 
> proportion to the boilerplate reduced, it's not a defect but a feature that 
> these compiler errors go away. At the moment, it is a great idea to enable 
> some of these improvements for specific common use cases before the general 
> facilites for reflection and/or code-generation are improved in later 
> versions of Swift, since the user experience would be expected to remain the 
> same once those full facilities arrive.
> 
>> I realise I may seem to be overreacting, but I really do feel that strongly 
>> about what I fully believe is a mistake. I understand people's enthusiasm 
>> for the feature, I do; I hate boilerplate as much as the next developer, but 
>> as you say, it's not a reason to rush forward, especially when this is not 
>> something that can be easily changed later.
>> 
>> That's a big part of the problem; the decisions here are not just about 
>> trimming boilerplate for Equatable/Hashable, it's also about the potential 
>> overreach of every synthesised feature now and in the 

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

[Xiaodi Wu via swift-evolution]

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 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 until I've finished
> it, developers get distracted, leave things unfinished to go back to later,
> make typos etc. etc. To me declaring a conformance is a declaration of "my
> type will meet the requirements for this make, sure I do it", not "please,
> please use some magic to do this for me"; there needs to be a clear
> difference between the two.
>
>
> My conclusion isn't as pessimistic as yours, but I share your objections:
> Mixing a normal feature (protocols) with compiler magic doesn't feel right
> to me — wether it's Equatable, Hashable, Codable or Error.
> It's two different concepts with a shared name*, so I think even
> AutoEquatable wouldn't be the right solution, and something like #Equatable
> would be a much better indicator for what is happening.
>
> Besides that specific concern, I can't fight the feeling that the
> evolution process doesn't work well for proposals like this:
> It's a feature that many people just want to have as soon as possible, and
> concerns regarding the long-term effects are more or less washed away with
> eagerness.
>
> - Tino
>
> * for the same reason, I have big concerns whenever someone proposes to
> blur the line between tuples and arrays
>
>
> Agreed. To be clear though; in spite of my pessimism this *is* a feature
> that I *do* want, but I would rather not have it at all than have it
> implemented in a way that hides bugs and sets a horrible precedent for the
> future.
>

This was already touched upon during review, but to reiterate, the analogy
to default protocol implementations is meant specifically to address this
point about "hiding bugs." Yes, this feature cannot currently be
implemented as a default protocol implementation without magic; with better
reflection facilities there's a good chance that one day it might be, but
that's not the reason why it's being compared to default protocol
implementations. The reason for the comparison is that this feature only
"hides bugs" like a default protocol implementation "hides bugs" (in the
I-conformed-my-type-and-forgot-to-override-the-default-and-the-compiler-won't-remind-me-anymore
sense of "hiding bugs"), and the addition of default protocol
implementations, unless I'm mistaken, isn't even considered an API change
that requires Swift Evolution review.

Given Swift's emphasis on progressive disclosure, I'm fairly confident that
once reflection facilities and/or code-generation facilities improve, many
boilerplate-y protocol requirements will be given default implementations
where they cannot be written today. With every advance in expressiveness,
more protocol requirements that cannot currently have a default
implementation will naturally acquire them. Since the degree to which the
compiler will cease to give errors about non-implementation is directly in
proportion to the boilerplate reduced, it's not a defect but a feature that
these compiler errors go away. At the moment, it is a great idea to enable
some of these improvements for specific common use cases before the general
facilites for reflection and/or code-generation are improved in later
versions of Swift, since the user experience would be expected to remain
the same once those full facilities arrive.

I realise I may seem to be overreacting, but I really do feel that strongly
> about what I fully believe is a mistake. I understand people's enthusiasm
> for the feature, I do; I hate boilerplate as much as the next developer,
> but as you say, it's not a reason to rush forward, especially when this is
> not something that can be easily changed later.
>
> That's a big part of the problem; the decisions here are not just about
> trimming boilerplate for Equatable/Hashable, it's also about the potential
> overreach of every synthesised feature now and in the future as well.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 
>> mailto:swift-evolution@swift.org>>:
>> 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 until I've finished it, developers get 
>> distracted, leave things unfinished to go back to later, make typos etc. 
>> etc. To me declaring a conformance is a declaration of "my type will meet 
>> the requirements for this make, sure I do it", not "please, please use some 
>> magic to do this for me"; there needs to be a clear difference between the 
>> two.
> 
> My conclusion isn't as pessimistic as yours, but I share your objections: 
> Mixing a normal feature (protocols) with compiler magic doesn't feel right to 
> me — wether it's Equatable, Hashable, Codable or Error.
> It's two different concepts with a shared name*, so I think even 
> AutoEquatable wouldn't be the right solution, and something like #Equatable 
> would be a much better indicator for what is happening.
> 
> Besides that specific concern, I can't fight the feeling that the evolution 
> process doesn't work well for proposals like this:
> It's a feature that many people just want to have as soon as possible, and 
> concerns regarding the long-term effects are more or less washed away with 
> eagerness.
> 
> - Tino
> 
> * for the same reason, I have big concerns whenever someone proposes to blur 
> the line between tuples and arrays

Agreed. To be clear though; in spite of my pessimism this is a feature that I 
do want, but I would rather not have it at all than have it implemented in a 
way that hides bugs and sets a horrible precedent for the future.

I realise I may seem to be overreacting, but I really do feel that strongly 
about what I fully believe is a mistake. I understand people's enthusiasm for 
the feature, I do; I hate boilerplate as much as the next developer, but as you 
say, it's not a reason to rush forward, especially when this is not something 
that can be easily changed later.

That's a big part of the problem; the decisions here are not just about 
trimming boilerplate for Equatable/Hashable, it's also about the potential 
overreach of every synthesised feature now and in the future as well.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> 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 until I've finished it, developers get 
> distracted, leave things unfinished to go back to later, make typos etc. etc. 
> To me declaring a conformance is a declaration of "my type will meet the 
> requirements for this make, sure I do it", not "please, please use some magic 
> to do this for me"; there needs to be a clear difference between the two.

My conclusion isn't as pessimistic as yours, but I share your objections: 
Mixing a normal feature (protocols) with compiler magic doesn't feel right to 
me — wether it's Equatable, Hashable, Codable or Error.
It's two different concepts with a shared name*, so I think even AutoEquatable 
wouldn't be the right solution, and something like #Equatable would be a much 
better indicator for what is happening.

Besides that specific concern, I can't fight the feeling that the evolution 
process doesn't work well for proposals like this:
It's a feature that many people just want to have as soon as possible, and 
concerns regarding the long-term effects are more or less washed away with 
eagerness.

- Tino

* for the same reason, I have big concerns whenever someone proposes to blur 
the line between tuples and arrays___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nevin Brackett-Rozinsky via swift-evolution]

I am really glad this is happening, it will make implementing basic data
types much nicer, and it is exactly the sort of feature that saves
developers from having to waste time thinking about trivial rote
boilerplate both when writing and when reading code—an excellent and
welcome addition to the language.

As for Haravikk’s scenario of marking a type as Equatable to trigger an
error so you remember to implement the protocol later, you can achieve the
same goal by tagging it “MakeMeEquatable” instead. The compiler will give
an error (because there is no such protocol) and then you can come back to
fix it another time.

Nevin


On Wed, Aug 16, 2017 at 6:29 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Proposal Link: https://github.com/apple/swift-evolution/blob/master/
> proposals/0185-synthesize-equatable-hashable.md
>
> The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
> ran from August 9…15, 2017. Feedback for the feature was glowingly
> positive, and the proposal is accepted.  The core team discussed the
> concerns raised in the feedback thread for the proposal.  Here are some
> rough notes (not intended to be exhaustive), but it is important to
> recognize that the proposal follows the design of the auto-synthesized
> Codable proposal, and that many of these same points were discussed when it
> came up:
>
> - The core team feels that adding compiler magic for this case is
> reasonable because it solves an important user need, and doesn’t preclude
> the introduction of a more general feature (e.g. like a macro system, or
> Rust's ‘deriving’ feature) in the future.  When/if that feature is designed
> and built, the compiler magic can be replaced with standard library magic.
>
> - The hash value of a type is not intended to be stable across rebuilds or
> other changes to the code.  It is ok to change if fields are reordered, the
> standard library changes the hash function, etc.  Tony pointed this out
> on-thread, saying:  The stdlib documentation for hashValue states "Hash
> values are not guaranteed to be equal across different executions of your
> program. Do not save hash values to use during a future execution.”
>
> - The code synthesized is meant to feel like a default implementation that
> you’re getting for free from a (constrained) extension on the protocol.
> This is why conformance to the protocol itself is all that is required, not
> something like “AutoEquatable”.
>
> Many thanks to Tony Allevato for driving forward this proposal.  The patch
> just needs final code review now - I think we’re all looking forward to
> this landing, congrats!
>
> Chris Lattner
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> On 17 Aug 2017, at 18:04, Chris Lattner  wrote:
>> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>> 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 Equatable/Hashable. 
>>> Constrained extensions are allowed to use type information from the 
>>> constraint, so I don’t think there is an issue here.
>> 
>> And I disagree; this isn't a constraint extension either, not even close, 
>> we're talking here about automatic behaviour based upon variables the 
>> protocol knows literally nothing about, in a way that can result in new 
>> errors that are currently impossible (as you can't currently conform to 
>> Equatable without providing some kind of code to implement it).
> 
> I understand and recognize your concern.  Your points are apply equally to 
> the default implementation of the Codable protocols as well, and the core 
> team specifically discussed this.
> 
> 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 producing the same effect with 
> more efficient code.

Parts that the protocol specifically defines are fine, I've said as much; the 
part I object to is everything else as the issue here is that the protocol must 
make assumptions about the concrete type and I find that dangerous, especially 
on an existing protocol. I would argue that any default implementation using 
reflection to do the same is likewise flawed unless the behaviour is very 
carefully and very clearly defined as part of a contract that developers are 
explicitly opting in to.

But that's not what's happening here; Equatable is an existing and well 
understood protocol and you are proposing to change it arbitrarily to suddenly 
imply functionality that doesn't currently exist and which has the potential to 
introduce bugs.

I have seen not one shred of justification why this feature must be implicit 
through Equatable except that Codable does it, and frankly I don't find that 
even close to acceptable as a precedent at all as Codable is not preexisting, 
and personally I don't like it in Codable's case either, and wasn't aware of 
the discussion around it. But for Equatable we're talking about a preexisting 
protocol that will today catch 100% of missing conformance bugs, being changed 
such that that is no longer the case because of a default behaviour that will 
hide such bugs by making potentially flawed assumptions about a concrete type.

Frankly, setting a precedent for this kind of automated background reflective 
guesswork on basic protocols is a horrifying prospect to me, even more so if it 
is being introduced arbitrarily on existing protocols. At least with things 
like unit testing that reflect test methods the rules are clearly known from 
the outset (i.e- there's a clear naming convention for what is reflected, 
everything else is the developer's domain, you opt-in by following that naming 
convention), this is not the case here.

And what exactly is the burden from opting in explicitly? A different protocol 
name, a keyword or an attribute are not going to trouble developers, and will 
clarify exactly what they intended without hiding bugs. This is why I feel this 
hasn't been considered sufficiently at all, as no justification is given why 
"AutoEquatable" or whatever is somehow an unacceptable burden to clarify what a 
developer actually wanted.

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 until I've finished it, developers get 
distracted, leave things unfinished to go back to later, make typos etc. etc. 
To me declaring a conformance is a declaration of "my type will meet the 
requirements for this make, sure I do it", not "please, please use some magic 
to do this for me"; there needs to be a clear difference between the two.

This is an overreach, plain and simple. While it may seem small, I would 
frankly rather go back to coding everything in C++ than continue using Swift if 
this is to be the direction of travel, as there's a big a difference between 
convenience and trying to guess what a developer wanted. Cutting down on 
boilerplate is a fine goal, but it should be because I as the developer wanted 
it, not someone else who thinks they're doing me a favour despite knowing 
nothing about my code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo

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

[Chris Lattner via swift-evolution]

> 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 
>> 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, so I don’t think there is an issue here.
> 
> And I disagree; this isn't a constraint extension either, not even close, 
> we're talking here about automatic behaviour based upon variables the 
> protocol knows literally nothing about, in a way that can result in new 
> errors that are currently impossible (as you can't currently conform to 
> Equatable without providing some kind of code to implement it).

I understand and recognize your concern.  Your points are apply equally to the 
default implementation of the Codable protocols as well, and the core team 
specifically discussed this.

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 producing the same effect with more efficient code.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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 Equatable/Hashable. 
> Constrained extensions are allowed to use type information from the 
> constraint, so I don’t think there is an issue here.

And I disagree; this isn't a constraint extension either, not even close, we're 
talking here about automatic behaviour based upon variables the protocol knows 
literally nothing about, in a way that can result in new errors that are 
currently impossible (as you can't currently conform to Equatable without 
providing some kind of code to implement it).

It is no more comparable to a constrained extension than it is to a default 
implementation, as it is neither of these things; both of those are well 
defined by their very nature, this instead is utterly arbitrary. There is no 
justification that will make that any less true.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Bennett via swift-evolution]

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, so I don’t 
think there is an issue here.

> On Aug 17, 2017, at 4:12 AM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> 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, but I figure I might as well ask here) 
> 
> I'm not big on the specifics of Codable, but collections are usually a case 
> where you need to be careful about how exactly you encode them; i.e- you 
> usually only want to encode the length and the contents, not anything related 
> to the way in which they are actually stored. This way it doesn't matter if 
> the hashes change, as you recreate the Set like you're adding all the values 
> for the first time; any collisions should then be resolved as normal (i.e- 
> assigning into buckets of non-identical items with the same hash). Nothing in 
> a Set should ever be overwritten on the basis of its hash alone. Otherwise, 
> any code that requires a more stable hash value should be using something 
> other than Hashable to generate it.
> 
>> On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution 
>>  wrote:
>> 
> 
>> The code synthesized is meant to feel like a default implementation that 
>> you’re getting for free from a (constrained) extension on the protocol.  
>> This is why conformance to the protocol itself is all that is required, not 
>> something like “AutoEquatable”.  
> 
> 
> I still strongly feel that treating this like a default implementation is a 
> mistake, especially in the case of Equatable; we are literally talking here 
> about a feature that introduces the potential to hide bugs, and it is not the 
> same as a default implementation, not at all as it uses details of the 
> concrete type, rather than merely what is defined within the protocol itself, 
> you are talking here about using parts of a type that are not clearly 
> defined, to create an implementation that by its very nature must give 
> accurate results.
> 
> I mean, the whole point of a protocol is to define what we as developers need 
> to do in order to ensure correct behaviour; when we start talking about 
> providing that behaviour automatically with behind the scenes magic that 
> necessarily has to make assumptions about a type then you lose any ability to 
> guarantee correctness. I feel so strongly that this is a mistake that I would 
> rather never see this feature implemented than see it implemented in this 
> way, and feel that this concern has been trivialised and ignored.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Haravikk via swift-evolution]

> 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, but I figure I might as well ask here) 

I'm not big on the specifics of Codable, but collections are usually a case 
where you need to be careful about how exactly you encode them; i.e- you 
usually only want to encode the length and the contents, not anything related 
to the way in which they are actually stored. This way it doesn't matter if the 
hashes change, as you recreate the Set like you're adding all the values for 
the first time; any collisions should then be resolved as normal (i.e- 
assigning into buckets of non-identical items with the same hash). Nothing in a 
Set should ever be overwritten on the basis of its hash alone. Otherwise, any 
code that requires a more stable hash value should be using something other 
than Hashable to generate it.

> On 16 Aug 2017, at 23:29, Chris Lattner via swift-evolution 
>  wrote:
> 

> The code synthesized is meant to feel like a default implementation that 
> you’re getting for free from a (constrained) extension on the protocol.  This 
> is why conformance to the protocol itself is all that is required, not 
> something like “AutoEquatable”.  


I still strongly feel that treating this like a default implementation is a 
mistake, especially in the case of Equatable; we are literally talking here 
about a feature that introduces the potential to hide bugs, and it is not the 
same as a default implementation, not at all as it uses details of the concrete 
type, rather than merely what is defined within the protocol itself, you are 
talking here about using parts of a type that are not clearly defined, to 
create an implementation that by its very nature must give accurate results.

I mean, the whole point of a protocol is to define what we as developers need 
to do in order to ensure correct behaviour; when we start talking about 
providing that behaviour automatically with behind the scenes magic that 
necessarily has to make assumptions about a type then you lose any ability to 
guarantee correctness. I feel so strongly that this is a mistake that I would 
rather never see this feature implemented than see it implemented in this way, 
and feel that this concern has been trivialised and ignored.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

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
collisions would still be resolved by testing equality.)

*Technically* that's possible, I suppose, if (1) the developer reordered
the fields between runs, (2) the implementation of the hash function
changed between language versions, or (3) it involved some sort of runtime
nondeterminism or randomness. If we ignore the cases where the code or the
runtime has to be recompiled, then only (3) applies, and I don't foresee
the derived hashes being implemented non-deterministically.

For what it's worth, this doesn't seem like a problem that's unique to
synthesized requirements—it could happen with any type that changed its
hash or introduced nondeterminism.

On Wed, Aug 16, 2017 at 8:01 PM Xiaodi Wu  wrote:

> 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 Wed, Aug 16, 2017 at 6:16 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution <
>> swift-evolution@swift.org> 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, but I figure I might as well ask
>>> here)
>>>
>>> On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution <
>>> swift-evolution@swift.org> 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  wrote:
>>>
>>> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <
>>> swift-evolution@swift.org> 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 Lattner via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Proposal Link:
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>>>
>>> The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
>>> ran from August 9…15, 2017. Feedback for the feature was glowingly
>>> positive, and the proposal is accepted.  The core team discussed the
>>> concerns raised in the feedback thread for the proposal.  Here are some
>>> rough notes (not intended to be exhaustive), but it is important to
>>> recognize that the proposal follows the design of the auto-synthesized
>>> Codable proposal, and that many of these same points were discussed when it
>>> came up:
>>>
>>> - The core team feels that adding compiler magic for this case is
>>> reasonable because it solves an important user need, and doesn’t preclude
>>> the introduction of a more general feature (e.g. like a macro system, or
>>> Rust's ‘deriving’ feature) in the future.  When/if that feature is designed
>>> and built, the compiler magic can be replaced with standard library magic.
>>>
>>> - The hash value of a type is not intended to be stable across rebuilds
>>> or other changes to the code.  It is ok to change if fields are reordered,
>>> the standard library changes the hash function, etc.  Tony pointed this out
>>> on-thread, saying:  The stdlib documentation for hashValue states "Hash
>>> values are not guaranteed to be equal across different executions of your
>>> program. Do not save hash values to use during a future execution.”
>>>
>>> - The code synthesized is meant to feel like a default implementation
>>> that you’re getting for free from a (constrained) extension on the
>>> protocol.  This is why conformance to the protocol itself is all that is
>>> required, not something like “AutoEquatable”.
>>>
>>> Many thanks to Tony Allevato for driving forward this proposal.  The
>>> patch just needs final code review now - I think we’re all looking forward
>>> to this landing, congrats!
>>>
>>> Chris Lattner
>>> Review Manager
>>>
>>> _

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

[Xiaodi Wu via swift-evolution]

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 Wed, Aug 16, 2017 at 6:16 PM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:

> 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, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution <
> swift-evolution@swift.org> 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, but I figure I might as well ask
>> here)
>>
>> On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution <
>> swift-evolution@swift.org> 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  wrote:
>>
>> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <
>> swift-evolution@swift.org> 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 Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/
>> proposals/0185-synthesize-equatable-hashable.md
>>
>> The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
>> ran from August 9…15, 2017. Feedback for the feature was glowingly
>> positive, and the proposal is accepted.  The core team discussed the
>> concerns raised in the feedback thread for the proposal.  Here are some
>> rough notes (not intended to be exhaustive), but it is important to
>> recognize that the proposal follows the design of the auto-synthesized
>> Codable proposal, and that many of these same points were discussed when it
>> came up:
>>
>> - The core team feels that adding compiler magic for this case is
>> reasonable because it solves an important user need, and doesn’t preclude
>> the introduction of a more general feature (e.g. like a macro system, or
>> Rust's ‘deriving’ feature) in the future.  When/if that feature is designed
>> and built, the compiler magic can be replaced with standard library magic.
>>
>> - The hash value of a type is not intended to be stable across rebuilds
>> or other changes to the code.  It is ok to change if fields are reordered,
>> the standard library changes the hash function, etc.  Tony pointed this out
>> on-thread, saying:  The stdlib documentation for hashValue states "Hash
>> values are not guaranteed to be equal across different executions of your
>> program. Do not save hash values to use during a future execution.”
>>
>> - The code synthesized is meant to feel like a default implementation
>> that you’re getting for free from a (constrained) extension on the
>> protocol.  This is why conformance to the protocol itself is all that is
>> required, not something like “AutoEquatable”.
>>
>> Many thanks to Tony Allevato for driving forward this proposal.  The
>> patch just needs final code review now - I think we’re all looking forward
>> to this landing, congrats!
>>
>> Chris Lattner
>> Review Manager
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift

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

[Tony Allevato via swift-evolution]

>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, Aug 16, 2017 at 4:06 PM Robert Bennett via swift-evolution <
swift-evolution@swift.org> 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, but I figure I might as well ask
> here)
>
> On Aug 16, 2017, at 7:02 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Aug 16, 2017, at 5:59 PM, Rudolf Adamkovic via swift-evolution <
> swift-evolution@swift.org> 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  wrote:
>
> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution <
> swift-evolution@swift.org> 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 Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Proposal Link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>
> The review of SE-0185 “Synthesizing Equatable and Hashable conformance”
> ran from August 9…15, 2017. Feedback for the feature was glowingly
> positive, and the proposal is accepted.  The core team discussed the
> concerns raised in the feedback thread for the proposal.  Here are some
> rough notes (not intended to be exhaustive), but it is important to
> recognize that the proposal follows the design of the auto-synthesized
> Codable proposal, and that many of these same points were discussed when it
> came up:
>
> - The core team feels that adding compiler magic for this case is
> reasonable because it solves an important user need, and doesn’t preclude
> the introduction of a more general feature (e.g. like a macro system, or
> Rust's ‘deriving’ feature) in the future.  When/if that feature is designed
> and built, the compiler magic can be replaced with standard library magic.
>
> - The hash value of a type is not intended to be stable across rebuilds or
> other changes to the code.  It is ok to change if fields are reordered, the
> standard library changes the hash function, etc.  Tony pointed this out
> on-thread, saying:  The stdlib documentation for hashValue states "Hash
> values are not guaranteed to be equal across different executions of your
> program. Do not save hash values to use during a future execution.”
>
> - The code synthesized is meant to feel like a default implementation that
> you’re getting for free from a (constrained) extension on the protocol.
> This is why conformance to the protocol itself is all that is required, not
> something like “AutoEquatable”.
>
> Many thanks to Tony Allevato for driving forward this proposal.  The patch
> just needs final code review now - I think we’re all looking forward to
> this landing, congrats!
>
> Chris Lattner
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Bennett via swift-evolution]

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 
>  wrote:
> 
> 
>> 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  wrote:
>>> 
 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 Lattner via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
> 
> The review of SE-0185 “Synthesizing Equatable and Hashable conformance” 
> ran from August 9…15, 2017. Feedback for the feature was glowingly 
> positive, and the proposal is accepted.  The core team discussed the 
> concerns raised in the feedback thread for the proposal.  Here are some 
> rough notes (not intended to be exhaustive), but it is important to 
> recognize that the proposal follows the design of the auto-synthesized 
> Codable proposal, and that many of these same points were discussed when 
> it came up:
> 
> - The core team feels that adding compiler magic for this case is 
> reasonable because it solves an important user need, and doesn’t preclude 
> the introduction of a more general feature (e.g. like a macro system, or 
> Rust's ‘deriving’ feature) in the future.  When/if that feature is 
> designed and built, the compiler magic can be replaced with standard 
> library magic.
> 
> - The hash value of a type is not intended to be stable across rebuilds 
> or other changes to the code.  It is ok to change if fields are 
> reordered, the standard library changes the hash function, etc.  Tony 
> pointed this out on-thread, saying:  The stdlib documentation for 
> hashValue states "Hash values are not guaranteed to be equal across 
> different executions of your program. Do not save hash values to use 
> during a future execution.”
> 
> - The code synthesized is meant to feel like a default implementation 
> that you’re getting for free from a (constrained) extension on the 
> protocol.  This is why conformance to the protocol itself is all that is 
> required, not something like “AutoEquatable”.  
> 
> Many thanks to Tony Allevato for driving forward this proposal.  The 
> patch just needs final code review now - I think we’re all looking 
> forward to this landing, congrats!
> 
> Chris Lattner 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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  > wrote:
> 
>>> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 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 Lattner via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 Proposal Link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
  
 
 
 The review of SE-0185 “Synthesizing Equatable and Hashable conformance” 
 ran from August 9…15, 2017. Feedback for the feature was glowingly 
 positive, and the proposal is accepted.  The core team discussed the 
 concerns raised in the feedback thread for the proposal.  Here are some 
 rough notes (not intended to be exhaustive), but it is important to 
 recognize that the proposal follows the design of the auto-synthesized 
 Codable proposal, and that many of these same points were discussed when 
 it came up:
 
 - The core team feels that adding compiler magic for this case is 
 reasonable because it solves an important user need, and doesn’t preclude 
 the introduction of a more general feature (e.g. like a macro system, or 
 Rust's ‘deriving’ feature) in the future.  When/if that feature is 
 designed and built, the compiler magic can be replaced with standard 
 library magic.
 
 - The hash value of a type is not intended to be stable across rebuilds or 
 other changes to the code.  It is ok to change if fields are reordered, 
 the standard library changes the hash function, etc.  Tony pointed this 
 out on-thread, saying:  The stdlib documentation for hashValue states 
 "Hash values are not guaranteed to be equal across different executions of 
 your program. Do not save hash values to use during a future execution.”
 
 - The code synthesized is meant to feel like a default implementation that 
 you’re getting for free from a (constrained) extension on the protocol.  
 This is why conformance to the protocol itself is all that is required, 
 not something like “AutoEquatable”.  
 
 Many thanks to Tony Allevato for driving forward this proposal.  The patch 
 just needs final code review now - I think we’re all looking forward to 
 this landing, congrats!
 
 Chris Lattner 
 Review Manager
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rudolf Adamkovic via swift-evolution]

That's great. Thanks!

R+

> On 17 Aug 2017, at 00:46, John McCall  wrote:
> 
>> 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 Lattner via swift-evolution 
>>>  wrote:
>>> 
>>> Proposal Link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>>> 
>>> The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran 
>>> from August 9…15, 2017. Feedback for the feature was glowingly positive, 
>>> and the proposal is accepted.  The core team discussed the concerns raised 
>>> in the feedback thread for the proposal.  Here are some rough notes (not 
>>> intended to be exhaustive), but it is important to recognize that the 
>>> proposal follows the design of the auto-synthesized Codable proposal, and 
>>> that many of these same points were discussed when it came up:
>>> 
>>> - The core team feels that adding compiler magic for this case is 
>>> reasonable because it solves an important user need, and doesn’t preclude 
>>> the introduction of a more general feature (e.g. like a macro system, or 
>>> Rust's ‘deriving’ feature) in the future.  When/if that feature is designed 
>>> and built, the compiler magic can be replaced with standard library magic.
>>> 
>>> - The hash value of a type is not intended to be stable across rebuilds or 
>>> other changes to the code.  It is ok to change if fields are reordered, the 
>>> standard library changes the hash function, etc.  Tony pointed this out 
>>> on-thread, saying:  The stdlib documentation for hashValue states "Hash 
>>> values are not guaranteed to be equal across different executions of your 
>>> program. Do not save hash values to use during a future execution.”
>>> 
>>> - The code synthesized is meant to feel like a default implementation that 
>>> you’re getting for free from a (constrained) extension on the protocol.  
>>> This is why conformance to the protocol itself is all that is required, not 
>>> something like “AutoEquatable”.  
>>> 
>>> Many thanks to Tony Allevato for driving forward this proposal.  The patch 
>>> just needs final code review now - I think we’re all looking forward to 
>>> this landing, congrats!
>>> 
>>> Chris Lattner 
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>> 
>> The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran 
>> from August 9…15, 2017. Feedback for the feature was glowingly positive, and 
>> the proposal is accepted.  The core team discussed the concerns raised in 
>> the feedback thread for the proposal.  Here are some rough notes (not 
>> intended to be exhaustive), but it is important to recognize that the 
>> proposal follows the design of the auto-synthesized Codable proposal, and 
>> that many of these same points were discussed when it came up:
>> 
>> - The core team feels that adding compiler magic for this case is reasonable 
>> because it solves an important user need, and doesn’t preclude the 
>> introduction of a more general feature (e.g. like a macro system, or Rust's 
>> ‘deriving’ feature) in the future.  When/if that feature is designed and 
>> built, the compiler magic can be replaced with standard library magic.
>> 
>> - The hash value of a type is not intended to be stable across rebuilds or 
>> other changes to the code.  It is ok to change if fields are reordered, the 
>> standard library changes the hash function, etc.  Tony pointed this out 
>> on-thread, saying:  The stdlib documentation for hashValue states "Hash 
>> values are not guaranteed to be equal across different executions of your 
>> program. Do not save hash values to use during a future execution.”
>> 
>> - The code synthesized is meant to feel like a default implementation that 
>> you’re getting for free from a (constrained) extension on the protocol.  
>> This is why conformance to the protocol itself is all that is required, not 
>> something like “AutoEquatable”.  
>> 
>> Many thanks to Tony Allevato for driving forward this proposal.  The patch 
>> just needs final code review now - I think we’re all looking forward to this 
>> landing, congrats!
>> 
>> Chris Lattner 
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rudolf Adamkovič via swift-evolution]

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: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
> 
> The review of SE-0185 “Synthesizing Equatable and Hashable conformance” ran 
> from August 9…15, 2017. Feedback for the feature was glowingly positive, and 
> the proposal is accepted.  The core team discussed the concerns raised in the 
> feedback thread for the proposal.  Here are some rough notes (not intended to 
> be exhaustive), but it is important to recognize that the proposal follows 
> the design of the auto-synthesized Codable proposal, and that many of these 
> same points were discussed when it came up:
> 
> - The core team feels that adding compiler magic for this case is reasonable 
> because it solves an important user need, and doesn’t preclude the 
> introduction of a more general feature (e.g. like a macro system, or Rust's 
> ‘deriving’ feature) in the future.  When/if that feature is designed and 
> built, the compiler magic can be replaced with standard library magic.
> 
> - The hash value of a type is not intended to be stable across rebuilds or 
> other changes to the code.  It is ok to change if fields are reordered, the 
> standard library changes the hash function, etc.  Tony pointed this out 
> on-thread, saying:  The stdlib documentation for hashValue states "Hash 
> values are not guaranteed to be equal across different executions of your 
> program. Do not save hash values to use during a future execution.”
> 
> - The code synthesized is meant to feel like a default implementation that 
> you’re getting for free from a (constrained) extension on the protocol.  This 
> is why conformance to the protocol itself is all that is required, not 
> something like “AutoEquatable”.  
> 
> Many thanks to Tony Allevato for driving forward this proposal.  The patch 
> just needs final code review now - I think we’re all looking forward to this 
> landing, congrats!
> 
> Chris Lattner 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution