+1. This is the cleanest proposed solution I've seen to this problem. Like
many people, I've started breaking up a lot of my large classes like view
controllers that have multiple protocol conformances into separate
extensions, and this would let many of those diagnostics fall out naturally.


On Tue, Sep 20, 2016 at 7:50 AM Martin Waitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello everybody,
>
> Several suggestions are floating around about explicitly marking a
> method to implement a protocol requirement.
>
> E.g.:
>
> > class Foo : Bar {
> >       implement func foo() {...}
> > }
>
> However, with extensions we can already do something very similar:
>
>    class Foo {
>        ....
>    }
>    extension Foo: Bar {
>        func foo() {...}
>    }
>
> Maybe simply adding a new warning would already help.
> Extensions which introduce new protocol conformances could be reserved
> for those methods which are already defined within the protocol.
> Whenever such an extension contains an unrecognized method, we could
> issue a warning.
> Or maybe even an error, but we should allow private methods as an
> exception (for helper functions which are clearly not related to the
> protocol).
>
> This way, when the programmer wants to make sure that her new method is
> used by a protocol then she can simply put that method in an extension.
>
> --
> Martin
> _______________________________________________
> 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