[swift-evolution] Protocol non-conformance clause

[Xiaodi Wu]

The point is pretty much moot. In Erica's draft proposal, keywords are
required in any Swift code that hasn't been compiled in order to indicate
conformance. Under that scheme, it might be useful to be able to express
something like what Erica asked about in this email thread. I understood it
to be a factual question--is it or is it not possible to exclude one
particular conforming type from an extension of a protocol? The answer
seems to be that the it is not possible in current Swift syntax, which is
fine.

I understand that you are saying that it isn't currently necessary to use
such a feature for retroactive modeling and that it might be possible to
write an alternative proposal for keywords like `required` in which it
continues not to be necessary. I don't think there's any disagreement here.
On Sun, May 1, 2016 at 16:24 Thorsten Seitz <tseitz42 at icloud.com> wrote:

>
> Am 01.05.2016 um 03:03 schrieb Erica Sadun <erica at ericasadun.com>:
>
>
> On Apr 29, 2016, at 3:18 PM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>
>
> Am 29.04.2016 um 19:51 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
>
> Yes, certainly this works today. The motivation for Erica's question is
> that this would not work without modifying the third-party code if keywords
> were required to indicate implementation of protocol requirements.
>
>
> If I understood the motivation correctly, the requirements should protect
> against typos where I planned to *replace* a method but due to a typo
> instead created a new method and inherited the default (or superclass)
> implementation.
>
>
> extension A where !x:B {
>     ....
> }
>
>
> then conforming a type to A and B would exclude the type from inheriting
> the extension.
>
>
> I still don’t see the need for that. As my code example demonstrated an
> extension will not override an existing method in a conforming type and my
> other mail demonstrated that it is not necessary to have „required“
> keywords in existing code which is extended.
>
> Maybe I still haven’t understood the use case you are trying to solve. In
> that case I’d appreciate if you would give a complete example that shows
> what should happen why.
>
> -Thorsten
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160501/ca0db736/attachment.html>