[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

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

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

https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst

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>