[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Paul Cantrell]

> On Jul 22, 2016, at 3:15 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I wrote that subclassability is not an important element of safety
> **independent of overriding**.  If you don't allow any overriding,
> your code is always “resilient” enough to handle subclassing.

Code can make assumptions about a type having a fixed set of subclasses known at compile time:

    switch foo {
        case is YinFoo:
            ...
        case is YangFoo:
            ...
        default:
            fatalError("only two kinds of Foo known")
    }

Granted, code like this is usually a sign of a flawed design. Reasonable uses for the “fixed, known set of subtypes” pattern are rare.

Design quality questions aside, however, it is not strictly true that preventing all member overrides guarantees that code is resilient to unexpected subclassing.

Cheers,

Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/3f83f5ba/attachment.html>