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

[David Ungar via swift-evolution]

This strikes me as another good way to look at it.

Thanks guys,

- David

> On Aug 10, 2017, at 2:54 PM, Robert Bennett  wrote:
> 
> @Xiaodi I have a slightly different view of this. Currently, if you have a 
> type that conforms to a protocol, and you do not need to write any additional 
> code in order for the type to conform to the protocol, then the protocol must 
> have default implementations of its requirements. Because some types will be 
> able to conform to Equatable/Hashable without writing out the code to satisfy 
> the == and hashValue requirements, that logic (which you may or may not 
> subscribe to) would dictate that there is a default implementation of those 
> requirements (in this case, a magical default implementation that works for 
> many different types; maybe it uses Mirrors) — it certainly “feels” like 
> there is a default implementation to the user. And thus from an ergonomic 
> standpoint, these issues are not really orthogonal, even if they are distinct 
> implementation-wise.
> 
>> On Aug 10, 2017, at 5:41 PM, David Ungar > > wrote:
>> 
>> As long as I've been clear that the adoption of *this* proposal would 
>> transform a misspelling from a bug that the compiler catches to a bug that 
>> the compiler does not catch, I feel that my objection has been heard.
>> 
>> Thank you all,
>> 
>> - David
>> 
>>> On Aug 10, 2017, at 1:51 PM, Xiaodi Wu >> > wrote:
>>> 
>>> Right. The objection raised is applicable to the overriding of any default 
>>> implementation. However. _this_ proposal under review is about the 
>>> synthesis of a default implementation, and we shouldn’t try to invent new 
>>> syntax to address an orthogonal issue—and only partially at that.
>>> On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> Yes, thanks! Here’s the full proposal for those interested: 
>>> https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md
>>>  
>>> 
>>> 
>>> I think that if we want to deal with the issue of some mistake arising from 
>>> conforming to Equatable and/or Hashable, it should be through that 
>>> proposal, not something specific to Equatable and Hashable. This sort of 
>>> issue should not count against this Equatable/Hashable proposal.
>>> 
 On Aug 10, 2017, at 3:39 PM, Chris Lattner >>> > wrote:
 
> 
> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> I could have sworn that this sort of issue came up on this list earlier 
> this year… Someone proposed a mechanism encompassing all protocols, not 
> just Equatable and Hashable, to handle the issue of mistakenly believing 
> you’re overriding a default implementation. Having trouble finding it at 
> the moment.
 
 Is this what you’re thinking of?
 https://github.com/apple/swift-evolution/pull/724 
 
 
 -Chris
 
 
 
> .
> 
>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> If I understand it, merely adding Equatable or Hashable will cause the 
>> compiler to synthesize requirements. This syntax opens up the 
>> possibility for errors:
>> 
>> struct Snort: Hashable {
>> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
>> }
>> 
>> In the above example, the programmer meant to implement hashValue but 
>> misspelled it.
>> With the proposal as-is, the error could be covered up.
>> 
>> I would prefer to see a different syntax than merely adding conformance 
>> to "HashValue", in order to distinguish the two cases: explicit 
>> supplying the requirement vs synthesis.
>> 
>> Also, what if we want to extend this idea to other protocols? Perhaps 
>> some sort of modifier on the protocol name would be more orthogonal:
>> 
>> struct Foo: Synth Hashable, Equatable 
>> 
>> Would say that Hashable requirements get synthesized but Equatable ones 
>> do not.
>> 
>> Alternatively, it might be clearer, though more verbose to move the 
>> signalling inside:
>> 
>> struct Snort: Hashable {
>> synth hashValue
>> }
>> 
>> (I don't advocate this specific syntax, btw.) But it has the virtual of 
>> possibly making it clearer to read the code.
>> 
>> TL;DR: I favor the proposal but would prefer modification to make it 
>> more explicit.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 

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

[Robert Bennett via swift-evolution]

Sorry, I think I misunderstood your earlier email. I believe we are in 
agreement.

> On Aug 10, 2017, at 5:54 PM, Xiaodi Wu  wrote:
> 
> Yes, but to be clear, this is an objection that is equally applicable to any 
> change where a protocol requirement is given a default implementation.
> 
> Unless I’m mistaken, ordinarily, the addition of such a default 
> implementation isn’t even considered an API change and doesn’t require Swift 
> Evolution approval.
>> On Thu, Aug 10, 2017 at 16:41 David Ungar  wrote:
>> As long as I've been clear that the adoption of *this* proposal would 
>> transform a misspelling from a bug that the compiler catches to a bug that 
>> the compiler does not catch, I feel that my objection has been heard.
>> 
>> Thank you all,
>> 
>> - David
>> 
>> 
>>> On Aug 10, 2017, at 1:51 PM, Xiaodi Wu  wrote:
>>> 
>>> Right. The objection raised is applicable to the overriding of any default 
>>> implementation. However. _this_ proposal under review is about the 
>>> synthesis of a default implementation, and we shouldn’t try to invent new 
>>> syntax to address an orthogonal issue—and only partially at that.
>>> On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution 
>>>  wrote:
 Yes, thanks! Here’s the full proposal for those interested: 
 https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md
 
 I think that if we want to deal with the issue of some mistake arising 
 from conforming to Equatable and/or Hashable, it should be through that 
 proposal, not something specific to Equatable and Hashable. This sort of 
 issue should not count against this Equatable/Hashable proposal.
 
>> On Aug 10, 2017, at 3:39 PM, Chris Lattner  wrote:
>> 
>> 
>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution 
>>  wrote:
>> 
>> I could have sworn that this sort of issue came up on this list earlier 
>> this year… Someone proposed a mechanism encompassing all protocols, not 
>> just Equatable and Hashable, to handle the issue of mistakenly believing 
>> you’re overriding a default implementation. Having trouble finding it at 
>> the moment.
> 
> Is this what you’re thinking of?
> https://github.com/apple/swift-evolution/pull/724
> 
> -Chris
> 
> 
> 
>> .
>> 
>>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution 
>>>  wrote:
>>> 
>>> If I understand it, merely adding Equatable or Hashable will cause the 
>>> compiler to synthesize requirements. This syntax opens up the 
>>> possibility for errors:
>>> 
>>> struct Snort: Hashable {
>>> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
>>> }
>>> 
>>> In the above example, the programmer meant to implement hashValue but 
>>> misspelled it.
>>> With the proposal as-is, the error could be covered up.
>>> 
>>> I would prefer to see a different syntax than merely adding conformance 
>>> to "HashValue", in order to distinguish the two cases: explicit 
>>> supplying the requirement vs synthesis.
>>> 
>>> Also, what if we want to extend this idea to other protocols? Perhaps 
>>> some sort of modifier on the protocol name would be more orthogonal:
>>> 
>>> struct Foo: Synth Hashable, Equatable 
>>> 
>>> Would say that Hashable requirements get synthesized but Equatable ones 
>>> do not.
>>> 
>>> Alternatively, it might be clearer, though more verbose to move the 
>>> signalling inside:
>>> 
>>> struct Snort: Hashable {
>>> synth hashValue
>>> }
>>> 
>>> (I don't advocate this specific syntax, btw.) But it has the virtual of 
>>> possibly making it clearer to read the code.
>>> 
>>> TL;DR: I favor the proposal but would prefer modification to make it 
>>> more explicit.
>>> ___
>>> 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] SE-0185 Synthesizing Equatable and Hashable conformance

[Robert Bennett via swift-evolution]

@Xiaodi I have a slightly different view of this. Currently, if you have a type 
that conforms to a protocol, and you do not need to write any additional code 
in order for the type to conform to the protocol, then the protocol must have 
default implementations of its requirements. Because some types will be able to 
conform to Equatable/Hashable without writing out the code to satisfy the == 
and hashValue requirements, that logic (which you may or may not subscribe to) 
would dictate that there is a default implementation of those requirements (in 
this case, a magical default implementation that works for many different 
types; maybe it uses Mirrors) — it certainly “feels” like there is a default 
implementation to the user. And thus from an ergonomic standpoint, these issues 
are not really orthogonal, even if they are distinct implementation-wise.

> On Aug 10, 2017, at 5:41 PM, David Ungar  wrote:
> 
> As long as I've been clear that the adoption of *this* proposal would 
> transform a misspelling from a bug that the compiler catches to a bug that 
> the compiler does not catch, I feel that my objection has been heard.
> 
> Thank you all,
> 
> - David
> 
>> On Aug 10, 2017, at 1:51 PM, Xiaodi Wu > > wrote:
>> 
>> Right. The objection raised is applicable to the overriding of any default 
>> implementation. However. _this_ proposal under review is about the synthesis 
>> of a default implementation, and we shouldn’t try to invent new syntax to 
>> address an orthogonal issue—and only partially at that.
>> On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> Yes, thanks! Here’s the full proposal for those interested: 
>> https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md
>>  
>> 
>> 
>> I think that if we want to deal with the issue of some mistake arising from 
>> conforming to Equatable and/or Hashable, it should be through that proposal, 
>> not something specific to Equatable and Hashable. This sort of issue should 
>> not count against this Equatable/Hashable proposal.
>> 
>>> On Aug 10, 2017, at 3:39 PM, Chris Lattner >> > wrote:
>>> 
 
 On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 I could have sworn that this sort of issue came up on this list earlier 
 this year… Someone proposed a mechanism encompassing all protocols, not 
 just Equatable and Hashable, to handle the issue of mistakenly believing 
 you’re overriding a default implementation. Having trouble finding it at 
 the moment.
>>> 
>>> Is this what you’re thinking of?
>>> https://github.com/apple/swift-evolution/pull/724 
>>> 
>>> 
>>> -Chris
>>> 
>>> 
>>> 
 .
 
> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> If I understand it, merely adding Equatable or Hashable will cause the 
> compiler to synthesize requirements. This syntax opens up the possibility 
> for errors:
> 
> struct Snort: Hashable {
> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
> }
> 
> In the above example, the programmer meant to implement hashValue but 
> misspelled it.
> With the proposal as-is, the error could be covered up.
> 
> I would prefer to see a different syntax than merely adding conformance 
> to "HashValue", in order to distinguish the two cases: explicit supplying 
> the requirement vs synthesis.
> 
> Also, what if we want to extend this idea to other protocols? Perhaps 
> some sort of modifier on the protocol name would be more orthogonal:
> 
> struct Foo: Synth Hashable, Equatable 
> 
> Would say that Hashable requirements get synthesized but Equatable ones 
> do not.
> 
> Alternatively, it might be clearer, though more verbose to move the 
> signalling inside:
> 
> struct Snort: Hashable {
> synth hashValue
> }
> 
> (I don't advocate this specific syntax, btw.) But it has the virtual of 
> possibly making it clearer to read the code.
> 
> TL;DR: I favor the proposal but would prefer modification to make it more 
> explicit.
> ___
> 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] SE-0185 Synthesizing Equatable and Hashable conformance

[Xiaodi Wu via swift-evolution]

Yes, but to be clear, this is an objection that is equally applicable to
any change where a protocol requirement is given a default implementation.

Unless I’m mistaken, ordinarily, the addition of such a default
implementation isn’t even considered an API change and doesn’t require
Swift Evolution approval.
On Thu, Aug 10, 2017 at 16:41 David Ungar  wrote:

> As long as I've been clear that the adoption of *this* proposal would
> transform a misspelling from a bug that the compiler catches to a bug that
> the compiler does not catch, I feel that my objection has been heard.
>
> Thank you all,
>
> - David
>
>
> On Aug 10, 2017, at 1:51 PM, Xiaodi Wu  wrote:
>
> Right. The objection raised is applicable to the overriding of any default
> implementation. However. _this_ proposal under review is about the
> synthesis of a default implementation, and we shouldn’t try to invent new
> syntax to address an orthogonal issue—and only partially at that.
> On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Yes, thanks! Here’s the full proposal for those interested:
>> https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md
>>
>> I think that if we want to deal with the issue of some mistake arising
>> from conforming to Equatable and/or Hashable, it should be through that
>> proposal, not something specific to Equatable and Hashable. This sort of
>> issue should not count against this Equatable/Hashable proposal.
>>
>> On Aug 10, 2017, at 3:39 PM, Chris Lattner  wrote:
>>
>>
>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I could have sworn that this sort of issue came up on this list earlier
>> this year… Someone proposed a mechanism encompassing all protocols, not
>> just Equatable and Hashable, to handle the issue of mistakenly believing
>> you’re overriding a default implementation. Having trouble finding it at
>> the moment.
>>
>>
>> Is this what you’re thinking of?
>> https://github.com/apple/swift-evolution/pull/724
>>
>> -Chris
>>
>>
>>
>> .
>>
>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> If I understand it, merely adding Equatable or Hashable will cause the
>> compiler to synthesize requirements. This syntax opens up the possibility
>> for errors:
>>
>> struct Snort: Hashable {
>> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
>> }
>>
>> In the above example, the programmer meant to implement hashValue but
>> misspelled it.
>> With the proposal as-is, the error could be covered up.
>>
>> I would prefer to see a different syntax than merely adding conformance
>> to "HashValue", in order to distinguish the two cases: explicit supplying
>> the requirement vs synthesis.
>>
>> Also, what if we want to extend this idea to other protocols? Perhaps
>> some sort of modifier on the protocol name would be more orthogonal:
>>
>> struct Foo: Synth Hashable, Equatable
>>
>> Would say that Hashable requirements get synthesized but Equatable ones
>> do not.
>>
>> Alternatively, it might be clearer, though more verbose to move the
>> signalling inside:
>>
>> struct Snort: Hashable {
>> synth hashValue
>> }
>>
>> (I don't advocate this specific syntax, btw.) But it has the virtual of
>> possibly making it clearer to read the code.
>>
>> TL;DR: I favor the proposal but would prefer modification to make it more
>> explicit.
>> ___
>> 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] SE-0185 Synthesizing Equatable and Hashable conformance

[David Ungar via swift-evolution]

As long as I've been clear that the adoption of *this* proposal would transform 
a misspelling from a bug that the compiler catches to a bug that the compiler 
does not catch, I feel that my objection has been heard.

Thank you all,

- David

> On Aug 10, 2017, at 1:51 PM, Xiaodi Wu  wrote:
> 
> Right. The objection raised is applicable to the overriding of any default 
> implementation. However. _this_ proposal under review is about the synthesis 
> of a default implementation, and we shouldn’t try to invent new syntax to 
> address an orthogonal issue—and only partially at that.
> On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Yes, thanks! Here’s the full proposal for those interested: 
> https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md
>  
> 
> 
> I think that if we want to deal with the issue of some mistake arising from 
> conforming to Equatable and/or Hashable, it should be through that proposal, 
> not something specific to Equatable and Hashable. This sort of issue should 
> not count against this Equatable/Hashable proposal.
> 
>> On Aug 10, 2017, at 3:39 PM, Chris Lattner > > wrote:
>> 
>>> 
>>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I could have sworn that this sort of issue came up on this list earlier 
>>> this year… Someone proposed a mechanism encompassing all protocols, not 
>>> just Equatable and Hashable, to handle the issue of mistakenly believing 
>>> you’re overriding a default implementation. Having trouble finding it at 
>>> the moment.
>> 
>> Is this what you’re thinking of?
>> https://github.com/apple/swift-evolution/pull/724 
>> 
>> 
>> -Chris
>> 
>> 
>> 
>>> .
>>> 
 On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 If I understand it, merely adding Equatable or Hashable will cause the 
 compiler to synthesize requirements. This syntax opens up the possibility 
 for errors:
 
 struct Snort: Hashable {
 static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
 }
 
 In the above example, the programmer meant to implement hashValue but 
 misspelled it.
 With the proposal as-is, the error could be covered up.
 
 I would prefer to see a different syntax than merely adding conformance to 
 "HashValue", in order to distinguish the two cases: explicit supplying the 
 requirement vs synthesis.
 
 Also, what if we want to extend this idea to other protocols? Perhaps some 
 sort of modifier on the protocol name would be more orthogonal:
 
 struct Foo: Synth Hashable, Equatable 
 
 Would say that Hashable requirements get synthesized but Equatable ones do 
 not.
 
 Alternatively, it might be clearer, though more verbose to move the 
 signalling inside:
 
 struct Snort: Hashable {
 synth hashValue
 }
 
 (I don't advocate this specific syntax, btw.) But it has the virtual of 
 possibly making it clearer to read the code.
 
 TL;DR: I favor the proposal but would prefer modification to make it more 
 explicit.
 ___
 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] SE-0185 Synthesizing Equatable and Hashable conformance

[Xiaodi Wu via swift-evolution]

Right. The objection raised is applicable to the overriding of any default
implementation. However. _this_ proposal under review is about the
synthesis of a default implementation, and we shouldn’t try to invent new
syntax to address an orthogonal issue—and only partially at that.
On Thu, Aug 10, 2017 at 14:45 Robert Bennett via swift-evolution <
swift-evolution@swift.org> wrote:

> Yes, thanks! Here’s the full proposal for those interested:
> https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md
>
> I think that if we want to deal with the issue of some mistake arising
> from conforming to Equatable and/or Hashable, it should be through that
> proposal, not something specific to Equatable and Hashable. This sort of
> issue should not count against this Equatable/Hashable proposal.
>
> On Aug 10, 2017, at 3:39 PM, Chris Lattner  wrote:
>
>
> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I could have sworn that this sort of issue came up on this list earlier
> this year… Someone proposed a mechanism encompassing all protocols, not
> just Equatable and Hashable, to handle the issue of mistakenly believing
> you’re overriding a default implementation. Having trouble finding it at
> the moment.
>
>
> Is this what you’re thinking of?
> https://github.com/apple/swift-evolution/pull/724
>
> -Chris
>
>
>
> .
>
> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If I understand it, merely adding Equatable or Hashable will cause the
> compiler to synthesize requirements. This syntax opens up the possibility
> for errors:
>
> struct Snort: Hashable {
> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
> }
>
> In the above example, the programmer meant to implement hashValue but
> misspelled it.
> With the proposal as-is, the error could be covered up.
>
> I would prefer to see a different syntax than merely adding conformance to
> "HashValue", in order to distinguish the two cases: explicit supplying the
> requirement vs synthesis.
>
> Also, what if we want to extend this idea to other protocols? Perhaps some
> sort of modifier on the protocol name would be more orthogonal:
>
> struct Foo: Synth Hashable, Equatable
>
> Would say that Hashable requirements get synthesized but Equatable ones do
> not.
>
> Alternatively, it might be clearer, though more verbose to move the
> signalling inside:
>
> struct Snort: Hashable {
> synth hashValue
> }
>
> (I don't advocate this specific syntax, btw.) But it has the virtual of
> possibly making it clearer to read the code.
>
> TL;DR: I favor the proposal but would prefer modification to make it more
> explicit.
> ___
> 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] SE-0185 Synthesizing Equatable and Hashable conformance

[Robert Bennett via swift-evolution]

Yes, thanks! Here’s the full proposal for those interested: 
https://github.com/erica/swift-evolution/blob/c541f517dacc2030c987b6d60ad3d26d8ec5fa3a/proposals/-role-keywords.md

I think that if we want to deal with the issue of some mistake arising from 
conforming to Equatable and/or Hashable, it should be through that proposal, 
not something specific to Equatable and Hashable. This sort of issue should not 
count against this Equatable/Hashable proposal.

> On Aug 10, 2017, at 3:39 PM, Chris Lattner  wrote:
> 
>> 
>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> I could have sworn that this sort of issue came up on this list earlier this 
>> year… Someone proposed a mechanism encompassing all protocols, not just 
>> Equatable and Hashable, to handle the issue of mistakenly believing you’re 
>> overriding a default implementation. Having trouble finding it at the moment.
> 
> Is this what you’re thinking of?
> https://github.com/apple/swift-evolution/pull/724 
> 
> 
> -Chris
> 
> 
> 
>> .
>> 
>>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution 
>>>  wrote:
>>> 
>>> If I understand it, merely adding Equatable or Hashable will cause the 
>>> compiler to synthesize requirements. This syntax opens up the possibility 
>>> for errors:
>>> 
>>> struct Snort: Hashable {
>>> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
>>> }
>>> 
>>> In the above example, the programmer meant to implement hashValue but 
>>> misspelled it.
>>> With the proposal as-is, the error could be covered up.
>>> 
>>> I would prefer to see a different syntax than merely adding conformance to 
>>> "HashValue", in order to distinguish the two cases: explicit supplying the 
>>> requirement vs synthesis.
>>> 
>>> Also, what if we want to extend this idea to other protocols? Perhaps some 
>>> sort of modifier on the protocol name would be more orthogonal:
>>> 
>>> struct Foo: Synth Hashable, Equatable 
>>> 
>>> Would say that Hashable requirements get synthesized but Equatable ones do 
>>> not.
>>> 
>>> Alternatively, it might be clearer, though more verbose to move the 
>>> signalling inside:
>>> 
>>> struct Snort: Hashable {
>>> synth hashValue
>>> }
>>> 
>>> (I don't advocate this specific syntax, btw.) But it has the virtual of 
>>> possibly making it clearer to read the code.
>>> 
>>> TL;DR: I favor the proposal but would prefer modification to make it more 
>>> explicit.
>>> ___
>>> 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] SE-0185 Synthesizing Equatable and Hashable conformance

[Chris Lattner via swift-evolution]

> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution 
>  wrote:
> 
> I could have sworn that this sort of issue came up on this list earlier this 
> year… Someone proposed a mechanism encompassing all protocols, not just 
> Equatable and Hashable, to handle the issue of mistakenly believing you’re 
> overriding a default implementation. Having trouble finding it at the moment.

Is this what you’re thinking of?
https://github.com/apple/swift-evolution/pull/724

-Chris



> .
> 
>> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution 
>>  wrote:
>> 
>> If I understand it, merely adding Equatable or Hashable will cause the 
>> compiler to synthesize requirements. This syntax opens up the possibility 
>> for errors:
>> 
>> struct Snort: Hashable {
>> static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
>> }
>> 
>> In the above example, the programmer meant to implement hashValue but 
>> misspelled it.
>> With the proposal as-is, the error could be covered up.
>> 
>> I would prefer to see a different syntax than merely adding conformance to 
>> "HashValue", in order to distinguish the two cases: explicit supplying the 
>> requirement vs synthesis.
>> 
>> Also, what if we want to extend this idea to other protocols? Perhaps some 
>> sort of modifier on the protocol name would be more orthogonal:
>> 
>> struct Foo: Synth Hashable, Equatable 
>> 
>> Would say that Hashable requirements get synthesized but Equatable ones do 
>> not.
>> 
>> Alternatively, it might be clearer, though more verbose to move the 
>> signalling inside:
>> 
>> struct Snort: Hashable {
>> synth hashValue
>> }
>> 
>> (I don't advocate this specific syntax, btw.) But it has the virtual of 
>> possibly making it clearer to read the code.
>> 
>> TL;DR: I favor the proposal but would prefer modification to make it more 
>> explicit.
>> ___
>> 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] SE-0185 Synthesizing Equatable and Hashable conformance

[Robert Bennett via swift-evolution]

I could have sworn that this sort of issue came up on this list earlier this 
year… Someone proposed a mechanism encompassing all protocols, not just 
Equatable and Hashable, to handle the issue of mistakenly believing you’re 
overriding a default implementation. Having trouble finding it at the moment.

> On Aug 10, 2017, at 3:09 PM, David Ungar via swift-evolution 
>  wrote:
> 
> If I understand it, merely adding Equatable or Hashable will cause the 
> compiler to synthesize requirements. This syntax opens up the possibility for 
> errors:
> 
> struct Snort: Hashable {
>  static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
> }
> 
> In the above example, the programmer meant to implement hashValue but 
> misspelled it.
> With the proposal as-is, the error could be covered up.
> 
> I would prefer to see a different syntax than merely adding conformance to 
> "HashValue", in order to distinguish the two cases: explicit supplying the 
> requirement vs synthesis.
> 
> Also, what if we want to extend this idea to other protocols? Perhaps some 
> sort of modifier on the protocol name would be more orthogonal:
> 
> struct Foo: Synth Hashable, Equatable 
> 
> Would say that Hashable requirements get synthesized but Equatable ones do 
> not.
> 
> Alternatively, it might be clearer, though more verbose to move the 
> signalling inside:
> 
> struct Snort: Hashable {
>  synth hashValue
> }
> 
> (I don't advocate this specific syntax, btw.) But it has the virtual of 
> possibly making it clearer to read the code.
> 
> TL;DR: I favor the proposal but would prefer modification to make it more 
> explicit.
> ___
> 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] SE-0185 Synthesizing Equatable and Hashable conformance

[David Ungar via swift-evolution]

If I understand it, merely adding Equatable or Hashable will cause the compiler 
to synthesize requirements. This syntax opens up the possibility for errors:

struct Snort: Hashable {
  static var hashValu /* NOTE MISSPELLING */ : Int { return 666 }
}

In the above example, the programmer meant to implement hashValue but 
misspelled it.
With the proposal as-is, the error could be covered up.

I would prefer to see a different syntax than merely adding conformance to 
"HashValue", in order to distinguish the two cases: explicit supplying the 
requirement vs synthesis.

Also, what if we want to extend this idea to other protocols? Perhaps some sort 
of modifier on the protocol name would be more orthogonal:

struct Foo: Synth Hashable, Equatable 

Would say that Hashable requirements get synthesized but Equatable ones do not.

Alternatively, it might be clearer, though more verbose to move the signalling 
inside:

struct Snort: Hashable {
  synth hashValue
}

(I don't advocate this specific syntax, btw.) But it has the virtual of 
possibly making it clearer to read the code.

TL;DR: I favor the proposal but would prefer modification to make it more 
explicit.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution