[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

[Matthew Johnson]

Sent from my iPad

> On Jul 8, 2016, at 12:30 PM, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> 1. As you point out, the majority of the surface area of idiomatic Swift APIs are unlikely to be impacted (value types, protocols, and final classes).  This is very likely to apply to future Swift-native APIs from Apple regardless of the outcome of this proposal.
>> 
>> 2. There is no impact on users of Apple's Objective-C APIs (AFAICT).
>> 
>> In the context of these facts, this proposal is not nearly as dramatic a change as many seem to be suggesting.
> It is dramatic, and your whole argument is flawed because you miss the imho most important point.

I didn't say it isn't dramatic, only that it isn't as dramatic a change as some commenters seem to suggest.

> This is not only a question of "will I be able to override this tiny method of UIView in the future?", but a question of attitude:
> When you do away with the rule of lenity and change it to "guilty by default", the direct impact is marginal as well — but it is a drastic change for the society as a whole.

It's not about guilt or innocence, or any kind of lenience or punishment.  

It's mostly about whether we want to foster an ecosystem where public API contracts have been explicitly considered or not.  There are some ancillary benefits as well but those are much less important.

> 
> Defaults matter, because they transmit a message:

I agree.

> Every rule and obstacle we add to Swift is a statement that says "we favor bureaucracy over freedom", and this will affect the community evolving around the language.
> When you use a library in a way that wasn't anticipated by its author, you'll ran into issues occasionally; nonetheless, I think we should struggle for an open ecosystem that encourages others to experiment and fail, rather than to limit their possibilities in a futile attempt to protect them.

In a majority of cases today this openness is better fostered by Github than "anything goes" public API.

> 
> Everyone should ask himself a simple question:
> When was the last time you you thought "I really wish the author of that library had restricted my options to use it"?

I really wish Objective-C had this feature from the start.  I believe there would have been significant benefits to Apple's platforms and ecosystem.  The reasons for believing (or not believing) this have been discussed in depth so there isn't a need to rehash them now.

> As a matter of fact, open by default forces nobody to subclass and override, so it's easy to avoid any problems caused by excessive hacking — closed by default, on the other hand, has impact not only on those who believe in restrictions, but on those who dislike them as well.

Actually open by default has caused some very nontrivial difficulties for Apple's framework maintainers.  We all pay the price for this whether we engage in such subclassing and overriding or not.  I find that pretty unfortunate, especially for those of us who do find other ways to solve our problems.

-Matthew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160708/9489bd6f/attachment.html>