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

> On Aug 14, 2016, at 2:17 AM, John Holdsworth via swift-evolution > wrote: > > 2) Contrary to arguments about the likely performance benefits of > de-virtualisation of method dispatch it is > likely to make Swift programs launch more slowly due to the dynamic linker > having to slide large n

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

Yeah I am fairly sure at this point in time "open" is purely about a statement of API contract (defaulted such to favor being explicit) which IMHO is a very good tool to have in the toolbox for module/framework developers. If it proves out to work well then I believe compiler optimizations could st

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 dispa

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 14:59

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

> Am 14.08.2016 um 14:59 schrieb Jean-Denis Muys via swift-evolution > : > > 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 ref

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 lo

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 behind the >> times and this proposal has been accepted :(

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 :( > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-p

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 > a écrit : > >

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 Swift 3. We plan to have ways t

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 Swif

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 :( > > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non

[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 o

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 >>> wrote: >>> >>> On Jun 29, 2016, at 9:54 PM, John McCall via swif

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: >> On Jun 29, 2016, at 12:05 PM, Michael Peternell wrote: I'm sti

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 < swift-evolution@swift.org>

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

Inline Regards (From mobile) On Jul 2, 2016, at 10:51 AM, Brent Royal-Gordon wrote: >> 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)

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 modules to extend the core set > of

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 know you're not proposing one, but it could start to

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 swift-evolu

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

Imma try again.. :P - everything is sealed within its module by default, no keyword - use “export” (formerly “public”) to mean “visible outside of the module, no subclassing or overriding externally, but overriding and subclasses allowed internally unless otherwise restricted” - use “export(p

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 principal of least > s

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 modu

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

> On Jul 1, 2016, at 10:51 AM, Michael Ilseman wrote: > If “opened”, who or what did the opening? If “open” is like “extensible”, > then I would interpret “opened” to be like “extended”. Yeah, I would prefer "open" to "opened". John. > >> On Jul 1, 2016, at 10:35 AM, Leonardo Pessoa via swift

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

If “opened”, who or what did the opening? If “open” is like “extensible”, then I would interpret “opened” to be like “extended”. > On Jul 1, 2016, at 10:35 AM, Leonardo Pessoa via swift-evolution > wrote: > > The proposal was to use "sealed" so why not "opened"? I understand it > may not be co

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 1

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 front of > things tha

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, in `internal` scope, you

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 an

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 overridabl

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

> On Jun 30, 2016, at 1:50 PM, Xiaodi Wu wrote: > On Thu, Jun 30, 2016 at 3:47 PM, John McCall > wrote: >> On Jun 30, 2016, at 1:44 PM, Xiaodi Wu > > wrote: >> On Thu, Jun 30, 2016 at 3:36 PM, John McCall > > wrote:

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

On Thu, Jun 30, 2016 at 3:47 PM, John McCall wrote: > 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, 2016 at 2:54 PM, John McCall via swift-evolution < >> swift-evolution@

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, 2016 at 2:54 PM, John McCall via swift-evolution >> mailto:swift-

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 wrote: >> > How about `public(extensible)`

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

> 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 > mailto:swift-evolution@swift.org>> wrote: > > On Jun 29, 2016, at 11:39 AM, Vladimir.S > > wrote: > > How about `public(extensible)` ? > > Hmm. I starte

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: > On Jun 29, 2016, at 10:17 PM, L. Mihalkovic > 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 PM, Vladimir.S via swift-evolution wrote: How about `publ

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: >>> >>> How about `public(extensible)` ? >>> >>> On 29.06.2016 21:32, John McCall v

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: On Jun 29, 2016, at 11:16 AM, Michael Peternell via swi

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 unhappy about this "sealed by default" proposal. That really >>> looks like premat

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 >> like premature optimization to me. Instead there should

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 swift-evolution >>> wrote: >>> Do you me

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Jun 29, 2016, at 3:45 PM, Rod Brown via swift-evolution >>> mailto:swift-evolution@swift.org>>

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 call it technically >> provides no actual optimisations.

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> From my understanding, "Sealed" or whatever we will call it technically >> provides no actual optimisa

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 the module may have vended a

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 vended a subclass. It can e

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 types

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 think I understand the

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

Sent from my iPad On Jun 29, 2016, at 2:54 PM, John McCall via swift-evolution 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 think I understand the need to c

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), but it may be confused with

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

> On Jun 29, 2016, at 12:05 PM, Michael Peternell > wrote: > I'm still unhappy about this "sealed by default" proposal. That really looks > like premature optimization to me. Instead there should be some `sealed` > keyword. Maybe it should be called `applepublic` :-p Everyone will understand! >

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

> 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 think I understand the need to combine them in some way. I wonder if just "extensible" would be good enough. It is a term that's u

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

I like `closed` better because it would pair up nicely with `opened` `opened` would be a good keyword imo (applying the ing/ed rule). In the future if we ever support open enums, we could use the same keyword. :) > On Jun 29, 2016, at 11:16 AM, John McCall via swift-evolution > wrote: > >

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

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). Also I think we should draw a guideline for such naming because there are always so many suggestions. Having a guideline would reduce our efforts in c

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

On 29.06.2016 22:05, Michael Peternell wrote: I'm still unhappy about this "sealed by default" proposal. That really looks like premature optimization to me. Instead there should be some `sealed` keyword. Maybe it should be called `applepublic` :-p Everyone will understand! I understand your po

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

I'm still unhappy about this "sealed by default" proposal. That really looks like premature optimization to me. Instead there should be some `sealed` keyword. Maybe it should be called `applepublic` :-p Everyone will understand! `sealed` classes should be a special optimization used by optimizin

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

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 swift-evolution wrote: Do you mean `public(unsealed)`? Because `internal(unsealed)` doesn't really make sense. `internal` declarations are always se

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 public classes and methods — and

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 syntax like > `internal(set

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

> On Jun 29, 2016, at 11:11 AM, Xiaodi Wu via swift-evolution > wrote: > Do we really need a new keyword? Since we already have syntax like > `internal(set)` couldn't we do `internal(unsealed)`, etc. The spelling is definitely up for debate. I remember that Chris in particular wasn't happy wi

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

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 already implemented? I think the keyword is `final`.. >

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 making it default. > > Aren't sealed classes already impl

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 : >>> >>> The decision to make class methods polymorphic by default was always

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

+1 for the concept of a "sealed” class. -1 for making it default. Would there be a benefit to having “sealed" protocols, as well? - Dave Sweeris On Jun 27, 2016, at 17:40, Javier Soto via swift-evolution mailto:swift-evolution@swift.org>> wrote: > Hello! > > I sent this as a PR

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 in obvious cases where methods are never >> over

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 methods are never >> overridden. Making a class pu

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 in obvious cases where methods are never >> ove

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 cause > significant p

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 >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 28, 2016, at 12:39 PM, Michael Peternell via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> Sea

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 >> the Swift core team is strong enough so that I cannot

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 implemented at all :) > > Why do

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 wrote: > On Jun 28, 2016, at 9:52 AM, Mark Lace

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 structs instead of classes, and

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 swift-evolution wrote: On Jun 27,

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 clear structured fashion that is well designed fo

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: >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic via swift-evolution

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: >>> >>> -1 for the fact that if all devs can write working code, fewer can do it

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 >>> wrote: >>> On Jun 27, 2016, at 9:10 PM, L. Mihalkovic

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 >>> wrote: >>> >>> -1 for the fact that if all devs can write workin

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 having sealed classes than not.

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 >> a clear structured fashion that is well designed for e

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 can treat it as final for oth

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 th

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 have

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

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 tod

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 PM,

[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: