[swift-evolution] [Proposal] Sealed classes by default

[John Holdsworth]

Well, I walked into that one :( Sorry to trawl all that up on a Sunday.

I get it now.  “open” is the new “public”, “public, the new “final” at
least as far as classes outside the module are concerned.

John

> On 15 Aug 2016, at 10:51, Tino Heth <2th at gmx.de> wrote:
> 
> 
>> Am 14.08.2016 um 14:59 schrieb Jean-Denis Muys via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>> This decision is bad, not because it makes the default for classes to be unsubclassable
> 
> Seems that the prediction of the grief caused by SE-0117 in the long run was right ;-) — but be careful, the title doesn't reflect reality anymore:
> As far as I understand, the default won't be changed at all.
> It has been internal, and it will be internal.
> The change is that changing the default to "public" will only make a class/method visible outside the current module, without the right to subclass/override.
> So, basically, "public" is renamed to "open".
> Imho this is still causing unnecessary trouble, as it breaks most libraries out there (more precisely: Third party code that relies on the old behavior), but in the future, you can just use "open" instead of "public", and little else will change — except that users of your framework may assume that "open" is an extension of "public", whereas you may follow the notion that "public" is an restriction of "open".
> 
> In the end, imho the whole topic has been decided in a very Solomonic way that disappoints both parties ;-), so I don't think it will be a reason for someone to fork Swift.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160815/1fa8d18a/attachment-0001.html>