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

> Am 21.07.2016 um 14:48 schrieb Tino Heth via swift-evolution > : > > >> Am 21.07.2016 um 13:52 schrieb Shawn Erickson via swift-evolution >> : >> >> Oops missed sending to the list. > it's quite easy to hit the wrong button — but

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

> On 21 Jul 2016, at 03:41, Brent Royal-Gordon wrote: > >> On Jul 20, 2016, at 3:26 PM, Karl wrote: >> >>> Sealed is *non-committal*. It makes no promises to wider scopes about >>> whether there are other subclasses/overrides; it merely states that

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

> On Jul 21, 2016, at 3:13 AM, Tino Heth via swift-evolution > wrote: > > >> Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution >> : >> >> A class that is closed in 1.0 can be opened in 1.1; a class that is `final` >>

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

> Am 21.07.2016 um 13:52 schrieb Shawn Erickson via swift-evolution > : > > Oops missed sending to the list. it's quite easy to hit the wrong button — but actually, the first recipient list was a better fit for the spirit of your motivation ;-) > Swift 3 is going to

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

> Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution > : > > A class that is closed in 1.0 can be opened in 1.1; a class that is `final` > in 1.0 *cannot* be opened in 1.1 (or at least it's a breaking change if it > is). Wait a moment: Aren't

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

> On Jul 20, 2016, at 3:26 PM, Karl wrote: > >> Sealed is *non-committal*. It makes no promises to wider scopes about >> whether there are other subclasses/overrides; it merely states that code >> outside the module may not subclass/override. `final`, on the other hand, is

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

+1 to Karl's suggestion I've come around to the idea of not allowing subclassing by default (well, 50/50) because I rarely see final used in swift code (read: it's underused). However, I think the special casing of 3rd party libraries is weird. Let's assume this is true: "It's really bad for

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

> limiting “open” to public classes only lets you be sloppy inside your own module. I don't find that idea bad actually. In the similar vein one can say "it's ok to be sloppy with local variable names, it's not ok to be sloppy with instance variable names". Again, tradeoffs. You can require

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

> On 20 Jul 2016, at 11:07, Brent Royal-Gordon wrote: > >> On Jul 19, 2016, at 6:14 PM, Karl wrote: >> >> That is to say, we basically introduce “open" as an inverted “final”, and >> make all classes non-open by default. That is analogous to

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

Regards (From mobile) On Jul 20, 2016, at 7:34 PM, John McCall via swift-evolution wrote: >>> On Jul 20, 2016, at 10:13 AM, Károly Lőrentey wrote: >>> On 2016-07-18, at 19:05, John McCall via swift-evolution >>>

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

What you said back then lead me to understand you did not get the difference. Forgive me if it wasn't the case but I've also seen it happen more than once in this list, hence the repeatition. I also understand that there are other ways to implement the same behaviour we want without sealed by

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

> On Jul 20, 2016, at 12:44 PM, Tino Heth via swift-evolution > wrote: > > >> Am 20.07.2016 um 18:20 schrieb L. Mihalkovic > >: >> >>> So my advice: Be glad that you don't see such problems in

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

> Am 18.07.2016 um 23:37 schrieb Leonardo Pessoa via swift-evolution > : > > Sealed methods can be overriden inside the defined module/library but > not outside. Same benefit of classes. Interesting how the supporters of the proposal seem to imply that the opponents

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

> Am 20.07.2016 um 18:20 schrieb L. Mihalkovic : > >> So my advice: Be glad that you don't see such problems in your real work >> life, and hope that the extremists who would like to completely remove >> classic object orientation and cripple Swift to fully match

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

> > However, once we've got non-open public classes — and as I understand it, > you still support those — that complexity already exists. You're not > really eliminating anything by preventing this from being applied to > methods. We may not need to prevent public members from being declared

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

> On 2016-07-20, at 19:34, John McCall wrote: > > I agree that having the concept of "visible publicly but only arbitrary > modifiable internally" adds complexity to the language. However, once we've > got non-open public classes — and as I understand it, you still

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

> On Jul 20, 2016, at 10:13 AM, Károly Lőrentey wrote: >> On 2016-07-18, at 19:05, John McCall via swift-evolution >> wrote: >> The basic effect of Károly's counter-proposal is that every public member of >> an open class has to be marked either

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

> On 2016-07-18, at 19:05, John McCall via swift-evolution > wrote: > The basic effect of Károly's counter-proposal is that every public member of > an open class has to be marked either "open" or "final". That's boilerplate. My primary point was that there is no

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

Regards LM (From mobile) > On Jul 20, 2016, at 9:54 AM, Tino Heth via swift-evolution > wrote: > > Hi Peter, > >> Am 20.07.2016 um 00:26 schrieb Peter Livesey via swift-evolution >> : >> >> 1. I don't understand what problem this

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

Just wanted to leave a quick +1 for the reworked version. `overridable` looked awful, but I reread the proposal, and `open` complements `final` nicely. ___ swift-evolution mailing list swift-evolution@swift.org

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

> On Jul 19, 2016, at 6:14 PM, Karl wrote: > > That is to say, we basically introduce “open" as an inverted “final”, and > make all classes non-open by default. That is analogous to enabling > whole-module-optimisation by default, in my opinion. The cost of an extra >

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

Hi Peter, > Am 20.07.2016 um 00:26 schrieb Peter Livesey via swift-evolution > : > > 1. I don't understand what problem this solves? That's just natural — most likely you have just a different mindset. There are already several cases where "bureaucrats try to

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

Sent from my iPhone > On 19 Jul 2016, at 23:36, L. Mihalkovic wrote: > > > > Regards > (From mobile) > >> On Jul 19, 2016, at 11:05 PM, Goffredo Marocchi wrote: >> >> >> >> Sent from my iPhone >> >>> On 19 Jul 2016, at 19:37, L.

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

The keyword `open` would only be required to allow subclassing **outside** of the module. You will still be able to subclass inside the module as long as it isn’t marked as `final`. This proposal wants classes to be `final`-by-default **outside** of the module and subclassable by default

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

I am ok with moving the public requirement for sealed-by-default. I have one qualm though. This would actually make starting out with the language a suboptimal experience. As (before, really) I teach what subclassing is, I have to explain this keyword to make subclassing possible. That sounds good

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

Just to clarify Karl, with your idea here, final wouldn't be necessary right? Since everything is already final by default? On Tue, Jul 19, 2016 at 6:15 PM Karl via swift-evolution < swift-evolution@swift.org> wrote: > > > On 17 Jul 2016, at 23:37, Brent Royal-Gordon >

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

> On 17 Jul 2016, at 23:37, Brent Royal-Gordon wrote: > >> On Jul 17, 2016, at 7:29 AM, Karl Wagner wrote: >> >> Open and public are orthogonal concepts, just like final and public are >> today. > > Are they? Given that "open" *means*

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

On Tue, Jul 19, 2016 at 6:26 PM, Peter Livesey via swift-evolution < swift-evolution@swift.org> wrote: > I'm new to this thread, but I've read every email so far. There are a few > things I find confusing with the proposal, so I'll try to sum up what I see > so far: > > 1. I don't understand what

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

Regards (From mobile) > On Jul 19, 2016, at 11:05 PM, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 19 Jul 2016, at 19:37, L. Mihalkovic wrote: >> >> >> >> Regards >> (From mobile) >> >>> On Jul 19, 2016, at 8:19 PM,

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

I'm new to this thread, but I've read every email so far. There are a few things I find confusing with the proposal, so I'll try to sum up what I see so far: 1. I don't understand what problem this solves? It seems like for 3rd party libraries only, we are afraid that people will subclass things

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

Sent from my iPhone > On 19 Jul 2016, at 21:41, David Owens II wrote: > > >> On Jul 19, 2016, at 11:37 AM, L. Mihalkovic via swift-evolution >> wrote: >> >> >> >> Regards >> (From mobile) >> >>> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi

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

Sent from my iPhone > On 19 Jul 2016, at 19:37, L. Mihalkovic wrote: > > > > Regards > (From mobile) > >> On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution >> wrote: >> >> >> Sent from my iPhone >> >>> >>>

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

> On Jul 19, 2016, at 11:37 AM, L. Mihalkovic via swift-evolution > wrote: > > > > Regards > (From mobile) > > On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution > > wrote: > >> >>

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

Regards (From mobile) > On Jul 19, 2016, at 8:19 PM, Goffredo Marocchi via swift-evolution > wrote: > > > Sent from my iPhone > >> >> Cocoa currently hides the boilerplate for all of these wonderful constructs >> behind amazingly effective runtime acrobatics.

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

Sent from my iPhone > > Cocoa currently hides the boilerplate for all of these wonderful constructs > behind amazingly effective runtime acrobatics. This fits perfectly into > Objective-C, and it also works very well in Swift. But such features could be > in better harmony with Swift's

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

On 2016-07-19 11:35:03 +, Brent Royal-Gordon via swift-evolution said: On Jul 19, 2016, at 4:00 AM, Károly Lőrentey via swift-evolution wrote: "dynamic final" is prohibited by the current version of compiler. Huh, I didn't know that. I don't agree with that

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

I was a little confused by this - I believe the previous proposal involved replacing final (and assuming it unless opened). I do not support "sealed". -1000 from me. I would absolutely holeheartedly support "final" by default; it's not very different to turning WMO on by default -

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

> On Jul 19, 2016, at 4:00 AM, Károly Lőrentey via swift-evolution > wrote: > > "dynamic final" is prohibited by the current version of compiler. Huh, I didn't know that. I don't agree with that design. (However, I do notice that a `final` class can have `dynamic`

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

On 2016-07-19 00:46:21 +, Brent Royal-Gordon via swift-evolution said: On Jul 18, 2016, at 12:06 PM, Károly Lőrentey via swift-evolution wrote: Introducing "dynamic" or some other keyword to mark explicitly methods that should be overriden is just the same

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

On 2016-07-18 21:42:03 +, Leonardo Pessoa via swift-evolution said: On 18 July 2016 at 16:06, Károly Lőrentey wrote: If adding an extra qualifier turns out to be an onerous requirement, we can choose a default at any time later, without breaking existing code.

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

> Taras Zakharko: I did a quick rudimentary regex through AppKit headers > looking for stuff like "((n't)|(not)).{1,15}override“ and its true that there > seem to be only a few dozens of documented methods where the documentation > explicitly warns agains overriding them. I have no idea how

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

> * What is your evaluation of the proposal? -1, I really think this a step in the wrong direction. I recognise the problem around this, and why something is needed. However, I don’t like the idea of restricting things by default. In the attempt to solve a problem, we will create more problems

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

> On 18 Jul 2016, at 18:31, Xiaodi Wu wrote: > > At the same time, your solution results in a lot of unnecessary boilerplate. > > It's an exaggeration to say that it's *a lot* of boilerplate. It's one line > or two in the base class. > Sure, it might be rare with

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

The revised proposal is much nicer. I'm still onboard on having classes sealed by default, but not as much on class members. Initially I felt that members should follow the same semantics as the class to avoid confusion, but I've read all the other emails I think I changed my mind. As

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

> On Jul 18, 2016, at 12:06 PM, Károly Lőrentey via swift-evolution > wrote: > >> Introducing "dynamic" or some other keyword to mark explicitly methods >> that should be overriden is just the same "open" with sealed methods >> by default would mean for public methods

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

On 18 July 2016 at 16:06, Károly Lőrentey wrote: > On 2016-07-18 16:15:10 +, Leonardo Pessoa via swift-evolution said: > >> I believe sealed by default applied to functions makes the behaviour >> consistent with classes and allows for the same behaviour we wanted >>

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

> On Jul 18, 2016, at 1:49 PM, L. Mihalkovic via swift-evolution > wrote: > > Regards > (From mobile) > >> On Jul 18, 2016, at 9:53 PM, Károly Lőrentey via swift-evolution >> wrote: >> >> If people were generally happy with having

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

I believe this is not in discussion anymore. We're just debating some specifics now. L On 18 July 2016 at 18:33, John Randolph via swift-evolution wrote: > - infinity for this proposal. > > If adopted, it will mean that whenever I want to extend a class implemented

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

Sealed methods can be overriden inside the defined module/library but not outside. Same benefit of classes. L On 18 July 2016 at 16:32, Garth Snyder via swift-evolution wrote: >> Nevin/Garth, please remember final and sealed are two different >> concepts: final

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

- infinity for this proposal. If adopted, it will mean that whenever I want to extend a class implemented by a short-sighted developer, I’ll have to resort to wrappers and classes that own instances of the lobotomized class, etc, etc. java.lang.string is final. I will never forgive Gosling

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

Regards (From mobile) > On Jul 18, 2016, at 9:53 PM, Károly Lőrentey via swift-evolution > wrote: > > If people were generally happy with having public members of open classes > overridable by default, then we certainly wouldn't need to have a separate > qualifier

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

Regards (From mobile) On Jul 18, 2016, at 7:12 PM, John McCall via swift-evolution wrote: >> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution >> wrote: >> I disagree that an `open` method overridden from a superclass

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

If people were generally happy with having public members of open classes overridable by default, then we certainly wouldn't need to have a separate qualifier for that. (Although as "internal" demonstrates, it's nice to have a formal name for such things.) However, (1) having a default would

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

Károly demonstrated that it’s already possible to achieve the effect of a nonoverridable method: > public open class UIViewController { > private var _view: UIView? = nil > > public final func loadViewIfNeeded() { > internalLoadViewIfNeeded() > } > >

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

On 2016-07-18 16:15:10 +, Leonardo Pessoa via swift-evolution said: I believe sealed by default applied to functions makes the behaviour consistent with classes and allows for the same behaviour we wanted with this proposal. It would allows us to create subclassable classes in which we

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

I would just like to voice my support for the current proposal and apologize in advance if this has already been adressed but the restriction on superclasses having to also be open is something I find awkward to say the least. To me it just seems that by doing so the issue of avoiding

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

Nevin/Garth, please remember final and sealed are two different concepts: final prevents anyone from subclassing/overriding while sealed prevents from subclassing/overriding *outside* the module they are declared. Thus final is not the same as sealed. L On 18 July 2016 at 15:45, Nevin

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

Garth makes an excellent point. Károly is correct that we can already achieve “sealed” by making a `final` member call through to an `internal` one. Therefore, it seem clear that “open” should only be applicable to classes, not to members. This should simplify the proposal nicely. Nevin On

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

> Károly wrote: I suggest we change the proposal to remove the implicit > "sealed" level of public member overridability, and support only "open" or > "final" class members. For members, "open" should mean the opposite of > "final", with no levels in between. Member-level openness should be

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

> On Jul 18, 2016, at 10:59 AM, Scott James Remnant wrote: >> On Jul 18, 2016, at 10:12 AM, John McCall wrote: >> >>> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution >>> wrote: >>> I disagree that an

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

> On Jul 18, 2016, at 10:12 AM, John McCall wrote: > >> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution >> wrote: >> I disagree that an `open` method overridden from a superclass is implicitly >> `open`. >> >> As the

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

Then we would need another keyword to close the method again should we need/want. public sealed override func foo() I don't see any association between override and open/sealed as they relate to two different aspects of class inheritance. One declares the method is overriding a superclass

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

> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution > wrote: > I disagree that an `open` method overridden from a superclass is implicitly > `open`. > > As the rationale for the proposal states, overridability is hard to get > right, and there is

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

> On Jul 18, 2016, at 9:31 AM, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Jul 18, 2016 at 11:24 AM, Taras Zakharko via swift-evolution > > wrote: > > > On 18 Jul 2016, at 14:07, Károly Lőrentey

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

On Mon, Jul 18, 2016 at 11:24 AM, Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote: > > > On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > I see no drawback to this pattern; it is quite clear and simple. >

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

> On 18 Jul 2016, at 14:07, Károly Lőrentey via swift-evolution > wrote: > > > I see no drawback to this pattern; it is quite clear and simple. Therefore, > in the interest of keeping the language free of needless complexity, I > suggest we change the proposal to

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

On Mon, Jul 18, 2016 at 7:07 AM, Károly Lőrentey wrote: > On 2016-07-18 09:17:43 +, David Hart via swift-evolution said: > > On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Mon, Jul 18, 2016 at 3:27 AM, Brent

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

On 2016-07-18 09:17:43 +, David Hart via swift-evolution said: On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution wrote: On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution wrote: > On Jul 17, 2016, at 8:57

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

Regards (From mobile) On Jul 18, 2016, at 10:27 AM, Brent Royal-Gordon wrote: >> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution >> wrote: >> >>> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution >>>

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

> On 18 Jul 2016, at 11:11, Xiaodi Wu via swift-evolution > wrote: > >> On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution >> wrote: >> > On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution >> >

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

On Mon, Jul 18, 2016 at 3:27 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution < >

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

> On Jul 17, 2016, at 8:57 PM, L. Mihalkovic via swift-evolution > wrote: > >> On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution >> wrote: >> >> Is there a summary somewhere of the motivation for allowing methods to be >>

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

Regards (From mobile) > On Jul 17, 2016, at 9:14 PM, Garth Snyder via swift-evolution > wrote: > > Is there a summary somewhere of the motivation for allowing methods to be > declared non-overridable within open classes? > > I’m not asking about any particular

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

I reviewed the original proposal, and this revised text is a much better step forwards; I still think there are a few changes I’d like to see before fully getting behind it. Consider this a +0.5. I like the use of the additional `open` keyword on top of `public`, it has a nice symmetry to the

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

> On Jul 17, 2016, at 7:29 AM, Karl Wagner wrote: > > Open and public are orthogonal concepts, just like final and public are today. Are they? Given that "open" *means* "subclassable/overridable in public scope", what would it mean for something to be open, but not public?

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

I too would be interested in this info. Brent's numbers look daunting indeed (nearly 2000 annotations for methods and properties in corelibs-foundation alone). What use cases are supported by sealed-but-not-final public methods in open classes? On Sun, Jul 17, 2016 at 2:14 PM, Garth Snyder via

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

Is there a summary somewhere of the motivation for allowing methods to be declared non-overridable within open classes? I’m not asking about any particular syntax or default, just why you'd want this facility at all. The proposal doesn’t mention this, and the discussion of the initial version

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

As an alternative to having `open` as a separate access level, we could instead have it merely imply `public`: the canonical form would be `public open`, but source code could just say `open`. Generated interfaces would always say `public open`, so searching for `public` in those would

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

> On Jul 15, 2016, at 10:52 PM, Chris Lattner wrote: > > * What is your evaluation of the proposal? I agree with the core team that closed by default for classes is the right move. I also think that it makes sense for methods to be closed by default. **However**, I