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
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
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
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
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,
> 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
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