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

Yeah I know - that's why I said it would only work if we are okay with saying non-open != final, as a long-term decision. So the compiler won't devirtualize those calls. As I understand it, that is how it works today - calls to non-open, non-final classes are still dynamically

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

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 <2...@gmx.de> wrote: > > >> Am 14.08.2016 um

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

This is a detail of implementation and doesn't have to be. You might even imagine the compiler emitting two versions of the code, one assuming the class will not be subclassed, the other not assuming that, and a smart linker linking the right version depending on the case. So for me, in the

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

> Le 14 août 2016 à 20:43, Karl via swift-evolution > a écrit : > > >> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution >> wrote: >> >> Hi folks, >> >> I see from building the latest Swift-3.0 branch that I’m a little

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

> On 14 Aug 2016, at 11:17, John Holdsworth via swift-evolution > wrote: > > Hi folks, > > I see from building the latest Swift-3.0 branch that I’m a little behind the > times and this proposal has been accepted :( > >

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

There was an order of magnitude more than 60 emails about this. In my inbox, I count 452 emails that have 0117 in the title. Discussion had already started before the proposal and I'm not counting these. Félix > Le 14 août 2016 à 02:17:36, John Holdsworth via swift-evolution >

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

> On Aug 14, 2016, at 5:59 AM, Jean-Denis Muys via swift-evolution > wrote: > > I for one would very much like this discussion to start again. To set expectations here, we are beyond the end of source breaking changes for Swift 3, so they cannot be changed for

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

I for one would very much like this discussion to start again. Yes it was discussed. Unfortunately, it was discussed in a summer time when in my country at least, many of us are off the grid for vacation. This is not a criticism of the process of course, just an indication that not everyone may

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

You are not familiar with us Italians and our love for (hopefully reasonable) arguing I see ;). I commit to and accept the decision taken, but it remains a decision I disagree with and something that will probably birth a painful fork once say Android and/or other big corporations moved to

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

> Le 14 août 2016 à 11:17, John Holdsworth via swift-evolution > a écrit : > > Hi folks, > > I see from building the latest Swift-3.0 branch that I’m a little behind the > times and this proposal has been accepted :( > >

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

Hi folks, I see from building the latest Swift-3.0 branch that I’m a little behind the times and this proposal has been accepted :( https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md Is there no way we can revisit this decision? 60 emails

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

> On Jul 2, 2016, at 10:58 AM, L. Mihalkovic > wrote: > > > Regards > LM > (From mobile) > > On Jun 30, 2016, at 9:12 AM, John McCall > wrote: > >>> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic

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

Regards LM (From mobile) On Jun 30, 2016, at 9:12 AM, John McCall wrote: >> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic >> wrote: >> >> On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution >> wrote: >>

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

+1 to sealed +1 to sealed-as-default. I prefer the need to explicitly share details that I would like to share. Separately, I do think that we need to improve the tools for auditing and organizing APIs. On Sat, Jul 2, 2016 at 8:35 AM, L. Mihalkovic via swift-evolution <

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

> On Jul 2, 2016, at 12:42 AM, L. Mihalkovic > wrote: > > This is a situation I often run into in jave where I would use an enum to > create a finite set of constants to be passed (say action identifers). But > then this makes it very difficult for external

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

Regards (From mobile) On Jul 1, 2016, at 6:43 PM, John McCall via swift-evolution wrote: >>> On Jul 1, 2016, at 2:08 AM, Brent Royal-Gordon >>> wrote: >>> That starts to look an awful lot like a fifth access level just for classes >>> (I

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

> On 1 Jul 2016, at 17:47, John McCall wrote: > > I don't think we'd ever use a compound keyword that starts with public; > we'd just separate them and say that the second half can only be present > on a public declaration, or do this parenthesized syntax. The `super` keyword could be reused:

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

I almost sent out an email with what you wrote. how about `public( nonfinal )` > - use “public(nonfinal)” to mean “exported out of the module, > subclass/overridable” I think just `open` would be a little bit better. `public( open )` > On Jul 1, 2016, at 11:20 AM, Sean Heber via

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

Ok, I suppose that this design *basically* undoes the sealed by default thing, doesn’t it? :P lol. One of those days, I guess.. Sigh. Crawling away… l8r Sean > On Jul 1, 2016, at 1:16 PM, Sean Heber wrote: > > Coming in late on this, but here’s my take guided by the

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

Coming in late on this, but here’s my take guided by the principal of least surprise (according to me): - everything is sealed within its module by default, no keyword - use “public” to mean “exported out of the module, subclass/overridable” - use “public(final)” to mean “exported out of the

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

The proposal was to use "sealed" so why not "opened"? I understand it may not be common to use "opened" as an adjective but from the dictionaries I consulted it is possible to. opened class MyViewController: UIViewController { opened func displayMe(_ me: person) { … } } On 1 July 2016 at

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

> On Jul 1, 2016, at 12:23 AM, Xiaodi Wu wrote: > That starts to look an awful lot like a fifth access level just for classes > (I know you're not proposing one, but it could start to look that way to a > user). I think there's much to be said for having the word public in

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

> On Jul 1, 2016, at 2:08 AM, Brent Royal-Gordon wrote: >> That starts to look an awful lot like a fifth access level just for classes >> (I know you're not proposing one, but it could start to look that way to a >> user). > > You know, it *could* be. > > Suppose that,

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

> That starts to look an awful lot like a fifth access level just for classes > (I know you're not proposing one, but it could start to look that way to a > user). You know, it *could* be. Suppose that, in `internal` scope, you can do all of these things: * Subclass a class. * Add a case to

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

That starts to look an awful lot like a fifth access level just for classes (I know you're not proposing one, but it could start to look that way to a user). I think there's much to be said for having the word public in front of things that are public. Unless, of course, your strawman keyword is a

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

> If we're going to go along those lines, we should just use > public(subclassable) and public(overridable). We can fall back on those if > necessary; I would just like to continue looking for better alternatives. I would prefer to have a *single* keyword which meant both public and

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

> On Jun 30, 2016, at 1:44 PM, Xiaodi Wu wrote: > On Thu, Jun 30, 2016 at 3:36 PM, John McCall > wrote: >> On Jun 29, 2016, at 1:33 PM, Xiaodi Wu > > wrote: >> On Wed, Jun 29,

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

On Thu, Jun 30, 2016 at 3:36 PM, John McCall wrote: > On Jun 29, 2016, at 1:33 PM, Xiaodi Wu wrote: > On Wed, Jun 29, 2016 at 2:54 PM, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > >> > On Jun 29, 2016, at 11:39 AM, Vladimir.S

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

Sent from my iPad On Jun 30, 2016, at 1:15 PM, John McCall via swift-evolution wrote: >>> On Jun 30, 2016, at 11:07 AM, Andrew Trick wrote: On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution wrote:

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

> On Jun 30, 2016, at 11:07 AM, Andrew Trick wrote: >> On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution >> wrote: >> >>> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic >>> wrote: On Jun 29, 2016, at 8:39

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

> On Jun 30, 2016, at 1:21 AM, John McCall via swift-evolution > wrote: > >> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic >> wrote: >>> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution >>> wrote:

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

> On Jun 29, 2016, at 10:17 PM, L. Mihalkovic > wrote: >> On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution >> wrote: >> >> How about `public(extensible)` ? >> >> On 29.06.2016 21:32, John McCall via swift-evolution wrote:

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

> On Jun 29, 2016, at 10:27 PM, L. Mihalkovic > wrote: > > On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution > wrote: > >>> On Jun 29, 2016, at 12:05 PM, Michael Peternell >>> wrote: >>> I'm still

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

Regards (From mobile) On Jun 29, 2016, at 9:54 PM, John McCall via swift-evolution wrote: >> On Jun 29, 2016, at 12:05 PM, Michael Peternell >> wrote: >> I'm still unhappy about this "sealed by default" proposal. That really looks >>

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

Regards (From mobile) > On Jun 29, 2016, at 8:39 PM, Vladimir.S via swift-evolution > wrote: > > How about `public(extensible)` ? > > On 29.06.2016 21:32, John McCall via swift-evolution wrote: >>> On Jun 29, 2016, at 11:16 AM, Michael Peternell via

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

> On Jun 29, 2016, at 4:05 PM, Matthew Johnson via swift-evolution > wrote: >> On Jun 29, 2016, at 5:56 PM, Mark Lacey via swift-evolution >> > wrote: >> >>> >>> On Jun 29, 2016, at 3:45 PM, Rod Brown via

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

> On Jun 29, 2016, at 6:05 PM, David Sweeris via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Jun 29, 2016, at 17:45, Rod Brown via swift-evolution >> wrote: >> >> From my understanding, "Sealed" or whatever we will

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

> On Jun 29, 2016, at 5:56 PM, Mark Lacey via swift-evolution > wrote: > >> >> On Jun 29, 2016, at 3:45 PM, Rod Brown via swift-evolution >> > wrote: >> >> From my understanding, "Sealed" or whatever we

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

Sent from my iPhone > On Jun 29, 2016, at 17:45, Rod Brown via swift-evolution > wrote: > > From my understanding, "Sealed" or whatever we will call it technically > provides no actual optimisations. We cannot assume the class is final because > something inside

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

> On Jun 29, 2016, at 3:45 PM, Rod Brown via swift-evolution > wrote: > > From my understanding, "Sealed" or whatever we will call it technically > provides no actual optimisations. We cannot assume the class is final because > something inside the module may have

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

From my understanding, "Sealed" or whatever we will call it technically provides no actual optimisations. We cannot assume the class is final because something inside the module may have vended a subclass. The issue that "sealed" as a concept fills is that you stop people from subclassing

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

On Wed, Jun 29, 2016 at 2:54 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 29, 2016, at 11:39 AM, Vladimir.S wrote: > > How about `public(extensible)` ? > > Hmm. I started to work out an example with these as separate modifiers, > and I

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

> Le 29 juin 2016 à 21:41, Leonardo Pessoa via swift-evolution > a écrit : > > I actually thought about something like 'public(final)' as it may make > it clearer the intention to the class (and no new keywords were > introduced). I also though about public(final),

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

> On Jun 29, 2016, at 11:16 AM, Michael Peternell via swift-evolution > wrote: > Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really > make sense. `internal` declarations are always sealed. Right. If "sealed" is the default behavior for

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

Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really make sense. `internal` declarations are always sealed. -Michael > Am 29.06.2016 um 20:11 schrieb Xiaodi Wu via swift-evolution > : > > Do we really need a new keyword? Since we already have

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

Do we really need a new keyword? Since we already have syntax like `internal(set)` couldn't we do `internal(unsealed)`, etc. On Wed, Jun 29, 2016 at 12:21 PM, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > On Jun 29, 2016, at 12:15 PM, Michael Peternell < >

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

> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution > : > > +1 for the concept of a "sealed” class. > -1 for making it default. Aren't sealed classes already implemented? I think the keyword is `final`.. So there is nothing left to do :)

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

> On Jun 29, 2016, at 12:15 PM, Michael Peternell > wrote: > > >> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >> : >> >> +1 for the concept of a "sealed” class. >> -1 for making it default. > > Aren't sealed classes

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

Sent from my iPhone > On Jun 29, 2016, at 12:15 PM, Michael Peternell via swift-evolution > wrote: > > >> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >> : >> >> +1 for the concept of a "sealed” class. >> -1 for

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

> Am 29.06.2016 um 08:33 schrieb Jean-Daniel Dupas via swift-evolution > : > > >> Le 29 juin 2016 à 01:01, Michael Peternell via swift-evolution >> a écrit : >> >> >>> Am 29.06.2016 um 00:32 schrieb John McCall : >>>

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

> Le 29 juin 2016 à 01:01, Michael Peternell via swift-evolution > a écrit : > > >> Am 29.06.2016 um 00:32 schrieb John McCall : >> >> The decision to make class methods polymorphic by default was always >> premised on being able to undo that

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

> On Jun 28, 2016, at 4:01 PM, Michael Peternell > wrote: >> Am 29.06.2016 um 00:32 schrieb John McCall : >> >> The decision to make class methods polymorphic by default was always >> premised on being able to undo that in obvious cases where

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

> On Jun 28, 2016, at 4:01 PM, Michael Peternell via swift-evolution > wrote: > > >> Am 29.06.2016 um 00:32 schrieb John McCall : >> >> The decision to make class methods polymorphic by default was always >> premised on being able to undo that

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

> Am 29.06.2016 um 00:32 schrieb John McCall : > > The decision to make class methods polymorphic by default was always premised > on being able to undo that in obvious cases where methods are never > overridden. Making a class public so that clients can use it shouldn't

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

> On Jun 28, 2016, at 2:20 PM, Christopher Kornher wrote: >> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution >> > wrote: >> >>> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution >>>

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

> On Jun 28, 2016, at 2:31 PM, John McCall via swift-evolution > wrote: > >> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution >> wrote: >> Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in >>

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

> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution > wrote: > Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in > the Swift core team is strong enough so that I cannot believe that this has a > chance of ever being

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

Sealing classes by default is a terrible idea IMHO. Fortunately, my faith in the Swift core team is strong enough so that I cannot believe that this has a chance of ever being implemented at all :) Why do I think it's terrible? I do subclass classes even when they say that you shouldn't do it.

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

Regards LM (From mobile) > On Jun 28, 2016, at 5:24 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Jun 28, 2016, at 10:17 AM, Mark Lacey via swift-evolution >> wrote: >> >> On Jun 28, 2016, at 7:55 AM, Sean Heber

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

> On Jun 28, 2016, at 8:09 AM, Javier Soto via swift-evolution > wrote: > IMO the issue with the argument that we wouldn't be able to "monkey patch" > things on sealed classes is that that is already the nature of Swift. The > designer of an API can choose to use

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

Regards LM (From mobile) > On Jun 28, 2016, at 4:59 PM, Charlie Monroe via swift-evolution > wrote: > > >>> On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution >>> wrote: >>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via

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

Regards LM (From mobile) > On Jun 28, 2016, at 4:52 PM, Mark Lacey wrote: > > >> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >> wrote: >> >> -1 for the fact that if all devs can write working code, fewer can do it in >> a

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

> On Jun 28, 2016, at 10:17 AM, Mark Lacey via swift-evolution > wrote: > > >> On Jun 28, 2016, at 7:55 AM, Sean Heber wrote: >> >>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >>> wrote: >>>

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

> On Jun 28, 2016, at 7:55 AM, Sean Heber wrote: > >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >> wrote: >> >>> >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >>> wrote: >>>

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

> On Jun 28, 2016, at 9:59 AM, Charlie Monroe via swift-evolution > wrote: > >> >> On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution >> wrote: >> >>> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >>>

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

IMO the issue with the argument that we wouldn't be able to "monkey patch" things on sealed classes is that that is already the nature of Swift. The designer of an API can choose to use structs instead of classes, and then there's already no way to "subclass". Moreover, "final" already exists, and

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

> On Jun 28, 2016, at 4:55 PM, Sean Heber via swift-evolution > wrote: > >> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution >> wrote: >> >>> >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >>>

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

> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution > wrote: > > -1 for the fact that if all devs can write working code, fewer can do it in a > clear structured fashion that is well designed for extensibility. This sounds more like an argument for

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

> On Jun 28, 2016, at 9:52 AM, Mark Lacey via swift-evolution > wrote: > >> >> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution >> wrote: >> >> -1 for the fact that if all devs can write working code, fewer can do it in >>

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

Regards LM (From mobile) > On Jun 28, 2016, at 1:57 PM, Alejandro Martinez via swift-evolution > wrote: > > Anton Zhilin: That is one of the points if I’m not mistaken. Sealed > means that with whole-module-optimization the compiler can optimise > more things as it

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

All bike-shedding aside, I see two parts of this proposal and I come down on different sides for the two. 1. Introducing a new class modifier that acts as final outside the defining module 2. Changing the default to this new modifier (and thus also introducing a third explicit class modifier

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

Anton Zhilin: That is one of the points if I’m not mistaken. Sealed means that with whole-module-optimization the compiler can optimise more things as it can treat it as final for other modules. L. Mihalkovic: Could you give an example of what exactly do you mean? I know one of the reasons behind

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

Does `sealed` allow for any optimizations? Maybe somehow devirtualizing method calls? ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

I'm a tentative +1, but I think we might consider a degree of "sealing", e.g- make extending the type a warning rather than an error, or require an attribute in order to force the extension. In other words, we make it perfectly clear that extending anyway is a bad idea, but still allow it to be

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

-1 for the fact that if all devs can write working code, fewer can do it in a clear structured fashion that is well designed for extensibility. A couple months ago I even ran into difficulties when trying to extend AlamoFire because some things had not been designed as cleanly as they could

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

I was also referring to how we present Objective-C classes in Swift. That is, if a Swift user tries to subclass an Objective-C-imported class, then we’d take into account sealed-ness in order to issue an error/warning, etc. If you are also proposing a Clang attribute for this, e.g.

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

That is a very good point, it should be explicitly mentioned in the proposal. My thought would be that since in the Obj-C runtime it's not possible to guarantee a class won't have subclasses, or that a method is not overriden, Obj-C classes would be imported as open. On the Swift side, I think

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

Could you elaborate on how we should treat classes imported from Objective-C or CF-style C? That is, do we always annotate them as being “open” because those paradigms permit subclassing anywhere, or do you propose some kind of recommended “sealed” audit, or what? > On Jun 27, 2016, at 3:40

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

Hello! I sent this as a PR on the swift-evolution repo, but we never had any discussion about it on-list, besides a long time ago . Here's the first draft of the proposal: