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

[Dave Abrahams]

on Fri Jul 22 2016, Paul Cantrell <swift-evolution at swift.org> wrote:

>> 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.

Point taken.

-- 
Dave