[swift-evolution] Keyword for protocol conformance

[David Cordero]

It sounds to me.

In fact it looks like we already have quite interesting information to
prepare a rough Draft to summarise all these scenarios in a real proposal.




On 23 August 2016 at 17:50, Xiaodi Wu via swift-evolution <
swift-evolution at swift.org> wrote:

> On Tue, Aug 23, 2016 at 2:13 AM, Charles Srstka <cocoadev at charlessoft.com>
> wrote:
>
>> On 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.
>>
>>
>> Had that happen to me a bunch of times, especially when I realize that
>> the method needs to have one more argument and then forget to add it
>> everywhere (which is harder to use search-and-replace for, as well).
>>
>> Here’s another case where this can bite you:
>>
>> In file P.swift:
>>
>> protocol P {
>> func foo()
>> }
>>
>> extension P {
>> func foo()
>> }
>>
>> In another file, S.swift:
>>
>> struct S: P {}
>>
>> Imagine I rename foo in the protocol, but forget to rename it in the
>> extension. The method no longer has a default implementation, and we do
>> indeed get an error, but the error’s in S.swift, in the wrong place. S
>> complains that it doesn’t conform to the protocol. If there were a keyword
>> on foo() in the extension, the compiler warning would be right where the
>> problem is as soon as I renamed the method in the protocol, and it’d be a
>> 2-second fix.
>>
>
> This is a great motivating example, I think. I'm convinced that we need
> some way to improve this scenario.
>
> That said, it'd probably have to be opt-in because major source-breaking
> changes are going to be frowned upon for Swift 4, and changing the syntax
> for every single protocol conformance would be hugely source-breaking. That
> said, I think an opt-in level of safety, where you mark particular
> declarations or even entire extensions as `@conforming` (or some similar
> syntax) would give the user most or all of these benefits while maintaining
> source compatibility. I would be +1 on a proposal like that.
>
>
>
>> 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/20160824/0d9bb02e/attachment.html>