[swift-evolution] Keyword for protocol conformance

Xiaodi Wu xiaodi.wu at gmail.com
Tue Aug 23 10:44:24 CDT 2016

On Tue, Aug 23, 2016 at 12:11 AM, Charlie Monroe <charlie at charliemonroe.net>

> I don't see it as sub-par in this example (this actually happened to me):
> @objc protocol Foo {
> optional func bar()
> }
> class FooImpl: Foo {
> func bar() { ... }
> }
> Now imagine that bar() gets renamed in the protocol to baz(). You get no
> warnings, nothing - since the bar() was optional (or can have default
> implementation as Chalers mentioned). FooImpl still conforms to Foo and
> bar() can live on there happily.

I think we're having a language barrier here :) Sub-par means inadequate,
and I think we're all in agreement that this behavior is inadequate.

> Yes, this could be solved by Xcode having a refactoring feature that works
> for Swift, or that you search & replace when renaming, but still doesn't
> solve when a 3rd party library does this and suddenly the behavior of your
> app changes completely. This goes against the compile-time safety Swift is
> about.
> Currently, when you mark a method on a protocol as
> @available(*, unavailable, renamed="baz")
> you do not get any warnings either - perhaps that's the issue here.

I think we should separate out the discussion about library evolution and
versioning. There's a huge amount of proposed and (I think) planned work
about that. Maybe the core team could chime in on how up-to-date this
document is:


If the true motivating problem here has to do with library evolution, then
we should probably study that document and wait to see how that planned
work turns out.

But if I understand it correctly, the true motivating problem here is the
poor experience of conforming to a protocol, the errors caused by typos
that effectively make protocol requirements stringily typed, and the
resultant unanticipated behaviors that arise, then we can have a useful
discussion about these issues without also trying to solve library
evolution with a single keyword.

> On the other hand, the naming may be completely coincidental and you can
> already have a method called bar() and it would then be impossible to
> conform to Foo unless you rename bar().
> What I'd propose is not to make keyword optional. In case you implement
> the members declared by the protocol, mark it as @conforming (or conforming
> keyword?).
> If it's retroactive modeling, redeclare the members. E.g.:
> extension Bar: Foo {
> // The implementation will be taken from Bar's main implementation
> @conforming func bar()
> }
> But yeah, it's a bit of boilerplate...
> On Aug 23, 2016, at 12:41 AM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> There's been agreement even from the core team that the quality of
> diagnostics when conforming to a protocol is sub-par.
> The modified rule you propose has also been suggested before. The reason
> it doesn't help is that (1) if a method signature is mismatched
> accidentally due to a typo, you get a compilation error already because
> your type doesn't conform to the protocol (it's the quality of the error
> message that needs improvement); (2) otherwise, if your type fulfills all
> protocol requirements but also implements an additional method unnecessary
> for conformance, what is the harm that is being prevented by a compiler
> error?
> On Mon, Aug 22, 2016 at 17:30 Charles Srstka <cocoadev at charlessoft.com>
> wrote:
>> On Aug 22, 2016, at 5:19 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> This has been proposed before in the past by several others (myself being
>> one of them).
>> The key problem is that it cannot accommodate retroactive modeling. That
>> is, you would not be able to conform existing types, the code for which you
>> do not control, to a protocol of your own design. Retroactive modeling is
>> an essential feature of Swift protocol-oriented programming.
>> Then how about making the keyword optional? A method or property with the
>> keyword before it would throw an error if it didn’t exist in one of the
>> protocols your type implements. This way, if you intended a method to
>> satisfy a protocol but left a typo in it, or you changed the protocol’s
>> signature in a refactoring or something, you’d get notified instead of not
>> finding out about it until runtime.
>> Charles
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160823/73ec6d32/attachment.html>

More information about the swift-evolution mailing list