@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 <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 
>> <mailto: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 <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/XXXX-role-keywords.md
>>  
>> <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 
>>> <mailto:clatt...@nondot.org>> wrote:
>>> 
>>>> 
>>>> On Aug 10, 2017, at 12:24 PM, Robert Bennett via swift-evolution 
>>>> <swift-evolution@swift.org <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 
>>> <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 <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 <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>> <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 
>>>> <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 
>> <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