[swift-evolution] Require use of override keyword to override dynamically dispatched methods defined in a protocol with a default implementation

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jan 6 02:36:18 CST 2016


> The pattern might exist for some existing classes or structs but it might still be useful for new classes or even for some existing ones to provide a default implementation.

I agree. It could be very useful in certain circumstances, and I agree
that any proposal that made this no longer possible would be a
non-starter. I had to think about this point for a bit; I hope I can
convince you that it would remain possible if overriding methods had
to use a keyword. The way it would be done would be valid code today,
and I think after some reflection that it's a superior way of doing
things even in today's Swift syntax because it's more explicit about
what's going on.

Example:
Given three existing struct types--

struct Foo {
    func boo() { print("foo boo") }
}
struct Bar { }
struct Baz { }

We wish to formalize after the fact, giving each type a method boo()
with a default implementation. Currently, this is valid Swift code--

protocol BooType {
    func boo()
}
extension BooType {
    func boo() { print("default boo") }
}
extension Foo: BooType { }
extension Bar: BooType { }
extension Baz: BooType { }

As you point out rightly, this would be invalid if we had to write
"override func boo()" in the body of struct Foo. However, this is
valid Swift code both in today's syntax and if my proposal were to be
implemented, and it is only one line longer--

protocol BooType {
    func boo()
}
protocol DefaultBooType: BooType { }
extension DefaultBooType {
    func boo() { print("default boo") }
}
extension Foo: BooType { }
extension Bar: DefaultBooType { }
extension Baz: DefaultBooType { }

I'd like to promote the second option as being superior even in
today's syntax. It is immediately clear to the reader that Foo().boo()
invokes a different method than Bar().boo(), even if the reader does
not have access to the original code for structs Foo, Bar, and Baz.
Suppose those structs were supplied in a third-party library that's
not well documented. It's plausible that a non-expert coder could try
to formalize after the fact and write an extension BooType
implementing boo() unaware that there is an overriding method in Foo.
In today's Swift syntax, the code would compile and behave subtly
differently from the author's expectations; as proposed, that code
would lead to a compile-time error. However, an expert coder who
intended to supply a default function but invoke any overriding
methods could write code that is almost as succinct but also
self-documenting, and in fact could do so today.


On Wed, Jan 6, 2016 at 12:45 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>
>
> > Am 06.01.2016 um 06:23 schrieb Xiaodi Wu via swift-evolution <swift-evolution at swift.org>:
> >
> > It would remain very much possible to formalize an existing pattern because, in the case of your example (unless I'm misunderstanding?), you are not also providing a default implementation of the "min" and "max" getters, and the IntXX structs would have nothing to override. Indeed, you'd hardly be formalizing an existing pattern if you had to supply de novo implementations!
>
> The pattern might exist for some existing classes or structs but it might still be useful for new classes or even for some existing ones to provide a default implementation.
>
> -Thorsten


More information about the swift-evolution mailing list