I believe the following idea was brought up on the list the last time this
topic came up, but I think it has a number of advantages and gets rid of the
need for a 'required' keyword completely. I have reservations on the 'override'
keyword as well, but the following idea would not preclude adding the
'override' keyword.
If an extension adds protocol conformance, only methods implementing the
protocol are allowed in the body. All methods from the protocol do not need to
be implemented in the extension, so long as the type conforms overall.
struct Foo {
func a() {}
}
protocol A {
func a()
}
protocol B {
func b()
}
protocol C {}
extension Foo: A { } // retroactive modeling, no error
extension Foo: B {
func b() {} // compiles, but "near miss" would not
}
extension Foo: C {
func d() {} // error, d() not part of protocol C
}
Advantages:
- Clarifies intent... If you are implementing a method in an extension that
declares a protocol conformance, it has to satisfy that one of that protocol's
requirements
- Eliminates "near-miss" mistakes when implementing a function in an extension
that declares protocol conformance, even in protocol has a default
implementation (it would be an error to implement the non-matching-but-almost
func)
- Fully supports retroactive modeling
- No new keywords required
Disadvantages:
- Source breaking change for any code that currently declares protocol
conformance in an extension and implements an unrelated method
- Potential inconsistency with base type declaration (does this rule apply only
to extensions or the initial declaration of the type?)
- Does not stop you from accidentally writing a implementation for a method
that already has a default implementation in the protocol (though nothing here
precludes the addition of adding 'override' as well)
Effectively, the only change required to current code would be to modify the
above implementation of:
extension Foo: C {
func d() {}
}
To read:
extension Foo: C {}
extension Foo {
func d() {}
}
On Apr 29, 2016, at 11:44, Stephen Canon via swift-evolution
<[email protected]> wrote:
>> On Apr 29, 2016, at 10:38 AM, Xiaodi Wu via swift-evolution
>> <[email protected]> wrote:
>>
>> I'd be keenly interested in something that would improve the experience of
>> conforming a type to a protocol. I think others would as well. A
>> sufficiently sophisticated solution would:
>>
>> * catch unintentional typos that cause required functions to be incorrectly
>> named
>> * show, ideally prospectively, which required functions have default
>> implementations
>> * clarify (and this is obviously a cherry-on-top scenario) what protocol
>> requirements any particular function helps to satisfy as well as which
>> combination of implementations is used to synthesize a default
>> implementation of another function (e.g. <= synthesized from < and ==; this
>> would help to determine whether it might be more efficient to roll your own
>> override)
>> * support all retroactive modeling scenarios currently supported
>>
>> I tried to propose a keyword-based solution (less sophisticated than yours)
>> a while back, and I've been convinced that the drawbacks in terms of
>> decreased expressiveness in retroactive modeling might be insurmountable.
>> Perhaps it would be worthwhile exploring improvements in tooling and
>> documentation (including annotation of the code itself) in order to address
>> some of these areas?
>
> Yeah, I think this is something that tooling / editors could really help
> with. I would love it if when I typed:
>
> struct Foo: Bar
>
> or
>
> extension Foo: Bar
>
> a skeleton with the missing Bar APIs was auto-generated for me to fill in.
> This would make it much easier to get conformances right, and require less
> typing instead of more.
>
> – Steve
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
