[swift-evolution] Keyword for protocol conformance

[David Cordero]

I agree with Charlie Monroe. I think it would improve the compile time
safety of Swift, making the keyword non optional.

The main issue with retroactive modelling is that it is applied to code to
which we might have no control at all. So this boilerplate definition would
allow the detection of changes on method signatures on this non controlled
code.

It might be easier to read having two different keywords for the 2
different cases. Something like the following code using `implement` when
implementing the protocol and `conform` when retroactive modeling

protocol MyProtocol {
    func method() -> String
}

class MyClass {

    implement func method() -> String {
        return "World"
    }
}

class MyNonControlledClass {

    func method() -> String {
        return "Hello"
    }
}


extension MyNonControlledClass: MyProtocol {
    conform method() -> String
}


Or even with a general way to declare a full conformance of a protocol:

extension MyNonControlledClass: conform(MyProtocol) {
}


On 23 August 2016 at 07:11, Charlie Monroe via swift-evolution <
swift-evolution at swift.org> 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.
>
> 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. 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
>
>
>
> _______________________________________________
> 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/d3b11b02/attachment.html>