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

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Aug 9, 2017, at 10:37 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Well, if there is one, then I apologize for bothering anyone. I just assumed 
> it would be included in the proposal itself, and I couldn't find it myself.  
> ;)

This is a good point. We'll update the proposal template with a link to the 
implementation. 

  - Doug

> 
> Thank you David.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 10. August 2017 um 07:30:16, David Hart (da...@hartbit.com) schrieb:
> 
>> 
>>> On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> Hi there, I don’t mean to be rude or something, nor do I want to hold the 
>>> review process up from succeeding, but where is the branch with the 
>>> implementation? 
>>> 
>>> Quote: 
>>> 
>>> The proposal phase for Swift 4 is now officially over
>>> I hope that the core team does not pick proposals they like, for instance 
>>> their own ones, and just skip the restriction of an implementation. I just 
>>> want to make sure that everyone plays with the same rules, so that it will 
>>> be fair for everyone
>>> 
>> I don’t know what gave you the impression the Core Team would bend the rules 
>> or play favorites. It’s not authored from an Apple engineer and, if you have 
>> a look at the PR for the proposal, there is a link to the implementation: 
>> https://github.com/apple/swift/pull/9619
>>> To strengthen up my criticism, here is a PR of a different proposal which 
>>> didn’t made it into Swift 4 but which was asked for an implementation 
>>> yesterday: 
>>> 
>>> https://github.com/apple/swift-evolution/pull/707
>>> 
>>> Have a nice review ;)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
>>> (swift-evolution@swift.org) schrieb:
>>> 
 And of course, the correct proposal link is:
 https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
 
 
 > On Aug 9, 2017, at 4:10 PM, Chris Lattner  wrote:
 > 
 > I forgot to mention that the implementation of this feature is available 
 > here:
 > https://github.com/apple/swift/pull/9619
 > 
 > -Chris
 > 
 >> On Aug 9, 2017, at 4:08 PM, Chris Lattner  wrote:
 >> 
 >> Hello Swift community,
 >> 
 >> The review of SE-0185 - "Synthesizing Equatable and Hashable 
 >> conformance" begins now and runs through August 15, 2017. The proposal 
 >> is available here:
 >> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
 >> 
 >> Reviews are an important part of the Swift evolution process. All 
 >> reviews should be sent to the swift-evolution mailing list at
 >> https://lists.swift.org/mailman/listinfo/swift-evolution
 >> 
 >> or, if you would like to keep your feedback private, directly to the 
 >> review manager. When replying, please try to keep the proposal link at 
 >> the top of the message:
 >> 
 >> What goes into a review?
 >> 
 >> The goal of the review process is to improve the proposal under review 
 >> through constructive criticism and, eventually, determine the direction 
 >> of Swift. When writing your review, here are some questions you might 
 >> want to answer in your review:
 >> 
 >> • What is your evaluation of the proposal?
 >> • Is the problem being addressed significant enough to warrant a change 
 >> to Swift?
 >> • Does this proposal fit well with the feel and direction of Swift?
 >> • If you have used other languages or libraries with a similar feature, 
 >> how do you feel that this proposal compares to those?
 >> • How much effort did you put into your review? A glance, a quick 
 >> reading, or an in-depth study?
 >> 
 >> More information about the Swift evolution process is available at:
 >> https://github.com/apple/swift-evolution/blob/master/process.md
 >> 
 >> 
 >> Thank you,
 >> 
 >> Chris Lattner
 >> Review Manager
 >> 
 >> 
 > 
 > ___
 > swift-evolution-announce mailing list
 > swift-evolution-annou...@swift.org
 > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
 
 ___
 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.s

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

[Matthew Johnson via swift-evolution]

> 
>   • What is your evaluation of the proposal?

Very large +1 in general.  I really wanted to see this happen in Swift 4.  I’m 
very happy that it’s up for review right at the beginning of the Swift 5 
process.

That said, I do think the concern others have voiced regarding implicit 
synthesis has some merit.  Most languages I am familiar with that synthesize 
memberwise implementations do so using an explicit request (`deriving` or 
similar).  It adds a small amount of boilerplate in exchange for precise 
control.  It seems to me that this tradeoff is in line with Swift’s motto of 
clarity over concision.  If we do make a change to this proposal we should also 
make the same change for basic enums as well as Codable for the sake of 
consistency.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes.  Manually writing memberwise implementations is a big enough annoyance 
that it can influence designs.  For example, a library author may be more 
likely to try and avoid requiring user types to conform when users are required 
to write those conformances manually. 

>   • Does this proposal fit well with the feel and direction of Swift?

Very much so.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

It is very similar, although as mentioned, it might make sense to require 
explicit opt-in to memberwise synthesis.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick glance this time around, but I have participated heavily in the previous 
discussions.

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

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

[Adrian Zubarev via swift-evolution]

Well, if there is one, then I apologize for bothering anyone. I just assumed it 
would be included in the proposal itself, and I couldn't find it myself. ;)  

Thank you David.

--  
Adrian Zubarev
Sent with Airmail  

Am 10. August 2017 um 07:30:16, David Hart 
(da...@hartbit.com(mailto:da...@hartbit.com)) schrieb:

>  
>  
> > On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution 
> > mailto:swift-evolution@swift.org)> wrote:  
> >  
> > Hi there, I don’t mean to be rude or something, nor do I want to hold the 
> > review process up from succeeding, but where is the branch with the 
> > implementation?  
> >  
> >  
> > Quote:  
> >  
> > > The proposal phase for Swift 4 is now officially over
> >  
> >  
> > I hope that the core team does not pick proposals they like, for instance 
> > their own ones, and just skip the restriction of an implementation. I just 
> > want to make sure that everyone plays with the same rules, so that it will 
> > be fair for everyone
> >  
> >  
> >  
>  
> I don’t know what gave you the impression the Core Team would bend the rules 
> or play favorites. It’s not authored from an Apple engineer and, if you have 
> a look at the PR for the proposal, there is a link to the implementation: 
> https://github.com/apple/swift/pull/9619
> >  
> > To strengthen up my criticism, here is a PR of a different proposal which 
> > didn’t made it into Swift 4 but which was asked for an implementation 
> > yesterday:  
> >  
> >  
> > https://github.com/apple/swift-evolution/pull/707
> >  
> >  
> > Have a nice review ;)
> >  
> >  
> >  
> >  
> >  
> >  
> > Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
> > (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb:
> >  
> > >  
> > > And of course, the correct proposal link is:
> > > https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
> > >  
> > >  
> > > > On Aug 9, 2017, at 4:10 PM, Chris Lattner 
> > > > mailto:clatt...@nondot.org)> wrote:
> > > >  
> > > > I forgot to mention that the implementation of this feature is 
> > > > available here:
> > > > https://github.com/apple/swift/pull/9619
> > > >  
> > > > -Chris
> > > >  
> > > >> On Aug 9, 2017, at 4:08 PM, Chris Lattner 
> > > >> mailto:clatt...@nondot.org)> wrote:
> > > >>  
> > > >> Hello Swift community,
> > > >>  
> > > >> The review of SE-0185 - "Synthesizing Equatable and Hashable 
> > > >> conformance" begins now and runs through August 15, 2017. The proposal 
> > > >> is available here:
> > > >> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
> > > >>  
> > > >> Reviews are an important part of the Swift evolution process. All 
> > > >> reviews should be sent to the swift-evolution mailing list at
> > > >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > > >>  
> > > >> or, if you would like to keep your feedback private, directly to the 
> > > >> review manager. When replying, please try to keep the proposal link at 
> > > >> the top of the message:
> > > >>  
> > > >> What goes into a review?
> > > >>  
> > > >> The goal of the review process is to improve the proposal under review 
> > > >> through constructive criticism and, eventually, determine the 
> > > >> direction of Swift. When writing your review, here are some questions 
> > > >> you might want to answer in your review:
> > > >>  
> > > >> • What is your evaluation of the proposal?
> > > >> • Is the problem being addressed significant enough to warrant a 
> > > >> change to Swift?
> > > >> • Does this proposal fit well with the feel and direction of Swift?
> > > >> • If you have used other languages or libraries with a similar 
> > > >> feature, how do you feel that this proposal compares to those?
> > > >> • How much effort did you put into your review? A glance, a quick 
> > > >> reading, or an in-depth study?
> > > >>  
> > > >> More information about the Swift evolution process is available at:
> > > >> https://github.com/apple/swift-evolution/blob/master/process.md
> > > >>  
> > > >>  
> > > >> Thank you,
> > > >>  
> > > >> Chris Lattner
> > > >> Review Manager
> > > >>  
> > > >>  
> > > >  
> > > > ___
> > > > swift-evolution-announce mailing list
> > > > swift-evolution-annou...@swift.org(mailto:swift-evolution-annou...@swift.org)
> > > > https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> > >  
> > > ___
> > > swift-evolution mailing list
> > > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >  
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org(mailto:swift-evolution@swift.org)
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>  
___
swift-evolution ma

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

[David Hart via swift-evolution]

> On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hi there, I don’t mean to be rude or something, nor do I want to hold the 
> review process up from succeeding, but where is the branch with the 
> implementation? 
> 
> Quote: 
> 
> The proposal phase for Swift 4 is now officially over
> I hope that the core team does not pick proposals they like, for instance 
> their own ones, and just skip the restriction of an implementation. I just 
> want to make sure that everyone plays with the same rules, so that it will be 
> fair for everyone
> 
I don’t know what gave you the impression the Core Team would bend the rules or 
play favorites. It’s not authored from an Apple engineer and, if you have a 
look at the PR for the proposal, there is a link to the implementation: 
https://github.com/apple/swift/pull/9619 
To strengthen up my criticism, here 
is a PR of a different proposal which didn’t made it into Swift 4 but which was 
asked for an implementation yesterday: 
> 
> https://github.com/apple/swift-evolution/pull/707 
> 
> Have a nice review ;)
> 
> 
> 
> 
> 
> Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> And of course, the correct proposal link is:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>>  
>> 
>> 
>> 
>> > On Aug 9, 2017, at 4:10 PM, Chris Lattner > > > wrote:
>> > 
>> > I forgot to mention that the implementation of this feature is available 
>> > here:
>> > https://github.com/apple/swift/pull/9619 
>> > 
>> > 
>> > -Chris
>> > 
>> >> On Aug 9, 2017, at 4:08 PM, Chris Lattner > >> > wrote:
>> >> 
>> >> Hello Swift community,
>> >> 
>> >> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
>> >> begins now and runs through August 15, 2017. The proposal is available 
>> >> here:
>> >> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
>> >>  
>> >> 
>> >> 
>> >> Reviews are an important part of the Swift evolution process. All reviews 
>> >> should be sent to the swift-evolution mailing list at
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> >> 
>> >> 
>> >> or, if you would like to keep your feedback private, directly to the 
>> >> review manager. When replying, please try to keep the proposal link at 
>> >> the top of the message:
>> >> 
>> >> What goes into a review?
>> >> 
>> >> The goal of the review process is to improve the proposal under review 
>> >> through constructive criticism and, eventually, determine the direction 
>> >> of Swift. When writing your review, here are some questions you might 
>> >> want to answer in your review:
>> >> 
>> >> • What is your evaluation of the proposal?
>> >> • Is the problem being addressed significant enough to warrant a change 
>> >> to Swift?
>> >> • Does this proposal fit well with the feel and direction of Swift?
>> >> • If you have used other languages or libraries with a similar feature, 
>> >> how do you feel that this proposal compares to those?
>> >> • How much effort did you put into your review? A glance, a quick 
>> >> reading, or an in-depth study?
>> >> 
>> >> More information about the Swift evolution process is available at:
>> >> https://github.com/apple/swift-evolution/blob/master/process.md 
>> >> 
>> >> 
>> >> 
>> >> Thank you,
>> >> 
>> >> Chris Lattner
>> >> Review Manager
>> >> 
>> >> 
>> > 
>> > ___
>> > swift-evolution-announce mailing list
>> > swift-evolution-annou...@swift.org 
>> > 
>> > https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>> > 
>> 
>> ___
>> 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

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

[Adrian Zubarev via swift-evolution]

Hi there, I don’t mean to be rude or something, nor do I want to hold the 
review process up from succeeding, but where is the branch with the 
implementation?

Quote:

The proposal phase for Swift 4 is now officially over
I hope that the core team does not pick proposals they like, for instance their 
own ones, and just skip the restriction of an implementation. I just want to 
make sure that everyone plays with the same rules, so that it will be fair for 
everyone.

To strengthen up my criticism, here is a PR of a different proposal which 
didn’t made it into Swift 4 but which was asked for an implementation yesterday:

https://github.com/apple/swift-evolution/pull/707

Have a nice review ;)




Am 10. August 2017 um 01:15:00, Chris Lattner via swift-evolution 
(swift-evolution@swift.org) schrieb:

And of course, the correct proposal link is:
https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md


> On Aug 9, 2017, at 4:10 PM, Chris Lattner  wrote:
>  
> I forgot to mention that the implementation of this feature is available here:
> https://github.com/apple/swift/pull/9619
>  
> -Chris
>  
>> On Aug 9, 2017, at 4:08 PM, Chris Lattner  wrote:
>>  
>> Hello Swift community,
>>  
>> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
>> begins now and runs through August 15, 2017. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
>>  
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>  
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>>  
>> What goes into a review?
>>  
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>>  
>> • What is your evaluation of the proposal?
>> • Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> • Does this proposal fit well with the feel and direction of Swift?
>> • If you have used other languages or libraries with a similar feature, how 
>> do you feel that this proposal compares to those?
>> • How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
>>  
>> More information about the Swift evolution process is available at:
>> https://github.com/apple/swift-evolution/blob/master/process.md
>>  
>>  
>> Thank you,
>>  
>> Chris Lattner
>> Review Manager
>>  
>>  
>  
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
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] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Howard Lovatt via swift-evolution]

>
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance".
> The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0185-synthesize-equatable-hashable.md
>
> • What is your evaluation of the proposal?
>

Overall a worthwhile addition. Specific comments:

   1. Opt in a good choice, see 2 below.
   2. Opt in should be for trivial enums as well, even though this is a
   breaking change it is clearer.
   3. The hash function should be more tightly specified, without
   specifying what it does it is hard to know if it is appropriate to use in a
   given application. I am not particularly advocating one hash function over
   another, but rather an explanation of what the user can expect. For example
   is hash consistent across invocations on the same machine and is it
   dependent upon the order of stored property declaration. It should also
   state that the hash function is not consistent across machines, since 32
   and 64 bit machines will have a different hash (as an implementation detail
   the hash function should be required to be different on different machines
   of the same architecture so that people do not mistakenly assume that for
   example all 64 bit machines produce the same hash). There has been a number
   of problems with the Java, Python, etc hash functions because these items
   were not specified.
   4. Specifying the exact hash function to be used could be considered, if
   the hash function is known then dictionary and dictionary like structures
   can be optimized.
   5. Synthesis by extensions in the same file should be considered, now
   that private extends to the file. (As an aside: also Codeable.)
   6. It is quite possible to have class types automatically synthesize
   hash and equality by calling super.hashValue and super.equals(Self). The
   omission seems at odds with treating classes equally to values.
   7. Same for tuples (should be included).
   8. Transient is a useful marker in Java and therefore should be
   considered (would also work well with Codeable).

Hope the above doesn't read negatively, the proposal as is would be a great
addition - the above are suggested improvements rather than show stopping
musts.


> • Is the problem being addressed significant enough to warrant a
> change to Swift?
>

Yes, I even have a library function that mimics this because I got fed up
of writing  boiler plate.

• Does this proposal fit well with the feel and direction of Swift?
>

Yes, part of rounding off the language.


> • If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>

Yes, see comments above based on experience with other languages


> • How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>

Something I have wanted for a while because I have used this feature in
other languages.

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

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

[Tony Allevato via swift-evolution]

On Wed, Aug 9, 2017 at 4:59 PM Michael Ilseman via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Aug 9, 2017, at 4:09 PM, Chris Lattner  wrote:
>
> Hello Swift community,
>
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance"
> begins now and runs through August 15, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
>
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at:
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> • What is your evaluation of the proposal?
>
>
>
> +1, it addresses one of the biggest pain points that cause people to reach
> for metaprogramming facilities.
>
> I have one clarifying point and tweak. The proposal states:
>
> A struct T: Hashable that satisfies the conditions above will receive a
> synthesized implementation of var hashValue: Int { get } that uses an
> unspecified hash function† to compute the hash value by incorporating the
> hash values of the fields as its terms, in definition order.
>
>
> This means that if the hash-combine operation is not commutative, then
> hashValues are not stable modulo member reordering. Was this scenario
> explicitly thought through? I don’t think it’s likely to be an issue in
> practice, but it's an artifact of implicit and ordered member-wise
> synthesis. It’s not obvious that declaration order is clearly the best
> order, e.g. declaration order is not necessarily memory-layout order. It
> might be better to leave the precise order unspecified, so long as it's
> guaranteed consistent during the execution of a program.
>

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.*"  So, we don't need to
provide member-reordering stability since the only way to reorder members
is to recompile the code (at this time).

That being said, we can certainly change the wording from "in definition
order" to "in an arbitrary, implementation-defined order" without changing
the behavior of the proposal and keeping the possibility open for future
optimizations.



>
> • Is the problem being addressed significant enough to warrant a change to
> Swift?
>
>
> Yes
>
> • Does this proposal fit well with the feel and direction of Swift?
>
>
> It's a reasonably scoped chunk of functionality for the biggest pain
> points, so yes.
>
> • If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
>
>
> Haskell and Rust both have “deriving" constructs for generating these
> kinds of things, and that simplifies a lot of code.
>
> • How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
>
>
> Thought about it a bit; read it quickly.
>
> More information about the Swift evolution process is available at:
> https://github.com/apple/swift-evolution/blob/master/process.md
>
>
> Thank you,
>
> Chris Lattner
> Review Manager
>
>
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
> ___
> 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] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

[Michael Ilseman via swift-evolution]

> On Aug 9, 2017, at 4:09 PM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
> begins now and runs through August 15, 2017. The proposal is available here:
> https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • What is your evaluation of the proposal?


+1, it addresses one of the biggest pain points that cause people to reach for 
metaprogramming facilities.

I have one clarifying point and tweak. The proposal states:

> A struct T: Hashable that satisfies the conditions above will receive a 
> synthesized implementation of var hashValue: Int { get } that uses an 
> unspecified hash function† to compute the hash value by incorporating the 
> hash values of the fields as its terms, in definition order.


This means that if the hash-combine operation is not commutative, then 
hashValues are not stable modulo member reordering. Was this scenario 
explicitly thought through? I don’t think it’s likely to be an issue in 
practice, but it's an artifact of implicit and ordered member-wise synthesis. 
It’s not obvious that declaration order is clearly the best order, e.g. 
declaration order is not necessarily memory-layout order. It might be better to 
leave the precise order unspecified, so long as it's guaranteed consistent 
during the execution of a program.

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes

>   • Does this proposal fit well with the feel and direction of Swift?

It's a reasonably scoped chunk of functionality for the biggest pain points, so 
yes.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Haskell and Rust both have “deriving" constructs for generating these kinds of 
things, and that simplifies a lot of code.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 

Thought about it a bit; read it quickly.

> More information about the Swift evolution process is available at:
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> 
> Thank you,
> 
> Chris Lattner
> Review Manager
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

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

[Chris Lattner via swift-evolution]

And of course, the correct proposal link is:
https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md


> On Aug 9, 2017, at 4:10 PM, Chris Lattner  wrote:
> 
> I forgot to mention that the implementation of this feature is available here:
> https://github.com/apple/swift/pull/9619
> 
> -Chris
> 
>> On Aug 9, 2017, at 4:08 PM, Chris Lattner  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" 
>> begins now and runs through August 15, 2017. The proposal is available here:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>>  • What is your evaluation of the proposal?
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
>>  • Does this proposal fit well with the feel and direction of Swift?
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at:
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> 
>> Thank you,
>> 
>> Chris Lattner
>> Review Manager
>> 
>> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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