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

> On Aug 10, 2017, at 5:54 PM, Xiaodi Wu <xiaodi...@gmail.com> 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 <dun...@apple.com> 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 <xiaodi...@gmail.com> 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/XXXX-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 <clatt...@nondot.org> 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

Reply via email to