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

> Publishing a library is a promise of something. It ought to only be promises > the library author wants to make. If “the truth” is “the implementation in > the current version of the library”, that’s definitely not what a library > author should promise. That’s true for plenty of things, not

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

> On Jul 12, 2016, at 13:44, Tino Heth <2...@gmx.de> wrote: > > Thanks for the detailed answer — I didn't expect it. > > I'll re-order the original message, since you had a genuine question (to bad > for me if it was just a rhetorical one :) whose answer might be more > interesting than the

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

Thanks for the detailed answer — I didn't expect it. I'll re-order the original message, since you had a genuine question (to bad for me if it was just a rhetorical one :) whose answer might be more interesting than the pointless remarks afterwards ;-) > If you were writing a library, what

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

> On Jul 11, 2016, at 00:50, Tino Heth via swift-evolution > wrote: > > >> In the implementation of the subclass, there has to be a call to one of the >> superclass's initializers. If all of the superclass’s initializers are >> non-public, then there’s no way to

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

2016/07/12 6:08、Jordan Rose via swift-evolution のメッセージ: > >> On Jul 11, 2016, at 04:34, Tino Heth <2...@gmx.de> wrote: >> >> I haven't read the whole Library Evolution document, but one important part >> is written right at the top: >> >>> This model is largely

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

> On Jul 11, 2016, at 04:34, Tino Heth <2...@gmx.de> wrote: > > I haven't read the whole Library Evolution document, but one important part > is written right at the top: > >> This model is largely not of interest to libraries that are bundled with >> their clients (distribution via source,

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

> On Jul 11, 2016, at 08:13, Leonardo Pessoa wrote: > > Jean, given this proposal it will be possible if the developer of the > library intends so. You'll have to have unsealed classes to be able to > subclass them and unsealed methods so you can override. It is possible > to

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

> Le 11 juil. 2016 à 17:43, Jordan Rose a écrit : > > >> On Jul 11, 2016, at 07:21, Jean-Daniel Dupas wrote: >> >> Just a though, but why sealed classes have to be completely unsubclassable ? >> >> Wouldn't it be possible to allow the user to

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

Regards (From mobile) > On Jul 11, 2016, at 9:43 PM, Tony Allevato via swift-evolution > wrote: > >> On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner wrote: >> Hello Swift community, >> >> The review of "SE-0117: Default classes to be

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

On Tue, Jul 5, 2016 at 4:11 PM Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > >

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

> On Jul 11, 2016, at 1:49 PM, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose > wrote: >> P.S. There’s also an argument to be made for public-but-not-conformable >>

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

On Mon, Jul 11, 2016 at 11:10 AM, Jordan Rose wrote: > P.S. There’s also an argument to be made for public-but-not-conformable >> protocols, i.e. protocols that can be used in generics and as values >> outside of a module, but cannot be conformed to. This is important for

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

> P.S. There’s also an argument to be made for public-but-not-conformable > protocols, i.e. protocols that can be used in generics and as values outside > of a module, but cannot be conformed to. This is important for many of the > same reasons as it is for classes, and we’ve gotten a few

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

> On Jul 8, 2016, at 8:41 PM, Jordan Rose wrote: >> On Jul 6, 2016, at 09:16, John McCall via swift-evolution >> > wrote: >> >>> On Jul 5, 2016, at 10:56 PM, Chris Lattner >>

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

> On Jul 11, 2016, at 07:21, Jean-Daniel Dupas wrote: > > Just a though, but why sealed classes have to be completely unsubclassable ? > > Wouldn't it be possible to allow the user to subclass sealed class, but deny > overriding of any public member. > > I see a use

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

Jean, given this proposal it will be possible if the developer of the library intends so. You'll have to have unsealed classes to be able to subclass them and unsealed methods so you can override. It is possible to just allow subclassing without allowing overriding, just like final. As for

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

Just a though, but why sealed classes have to be completely unsubclassable ? Wouldn't it be possible to allow the user to subclass sealed class, but deny overriding of any public member. I see a use case where a user want to extends an existing model by adding new properties and new methods to

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

Sent from my iPad > On Jul 10, 2016, at 10:38 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > ] > > (This is my second response to this

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

I haven't read the whole Library Evolution document, but one important part is written right at the top: > This model is largely not of interest to libraries that are bundled with > their clients (distribution via source, static library, or embedded/sandboxed > dynamic library, as used by the

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

> In the implementation of the subclass, there has to be a call to one of the > superclass's initializers. If all of the superclass’s initializers are > non-public, then there’s no way to write your own initializer. (This is > actually true in Swift today.) I want to point out that this

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

On Sun, Jul 10, 2016 at 10:38 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > ] > > (This is my second response to this proposal. The previous message

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md ] (This is my second response to this proposal. The previous message shared a use case where public-but-non-subclassable made things work out much better with required

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

To highlight your comment below - I would favor “sealed” being available, I’m not sure I would favor it being the default. Would it help to perhaps split this into two proposals. First, decide on the issue of sealable being available first and syntax for it. If this passes then a second

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

> On Jul 9, 2016, at 16:37, Károly Lőrentey via swift-evolution > wrote: > > On 2016-07-09 04:39:01 +, Jordan Rose via swift-evolution said: > >> I wanted to share a concrete use case that Daniel Dunbar relayed to me. He >> was working on a closed class

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

> On Jul 9, 2016, at 01:44, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 9 Jul 2016, at 05:39, Jordan Rose via swift-evolution >> wrote: >> >> Of course, Swift doesn’t allow this. If someone outside of the module >> subclasses

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

> On Jul 8, 2016, at 23:47, L. Mihalkovic wrote: > > > > Regards > (From mobile) > > On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution > > wrote: > >> [Proposal: >>

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

> On Jul 10, 2016, at 1:37 AM, Károly Lőrentey via swift-evolution > wrote: > > On 2016-07-09 04:39:01 +, Jordan Rose via swift-evolution said: > >> I wanted to share a concrete use case that Daniel Dunbar relayed to me. He >> was working on a closed class

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

On 2016-07-09 04:39:01 +, Jordan Rose via swift-evolution said: I wanted to share a concrete use case that Daniel Dunbar relayed to me. He was working on a closed class hierarchy like the ones discussed here, where all of the subclasses are within a single module, but they are all public.

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

On Tue, Jul 5, 2016, at 04:11 PM, Chris Lattner wrote: > * What is your evaluation of the proposal? Mixed bag. I'm a big fan of sealed-by-default for classes. But I want a keyword (e.g. `sealed`) for this so I can be explicit about it too. Just as I sometimes mark methods as `internal`

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

Sent from my iPhone > On 9 Jul 2016, at 05:39, Jordan Rose via swift-evolution > wrote: > > Of course, Swift doesn’t allow this. If someone outside of the module > subclasses ModelBase, there’s no way for them to provide the > dynamically-dispatched

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

Regards (From mobile) > On Jul 9, 2016, at 6:39 AM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md > ] > > John has done a tremendous job

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

> * What is your evaluation of the proposal? -1 Once, for an extended portion of my career, I worked in a 'developer support' type role for a large C++ API. I had daily contact with developers who were consuming that API. Because of that experience, I am fully convinced that library

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md ] John has done a tremendous job supporting this proposal; the position he’s articulated very closely matches mine. Thank you to both John and Javier. I wanted to share a

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

> On Jul 6, 2016, at 09:16, John McCall via swift-evolution > wrote: > >> On Jul 5, 2016, at 10:56 PM, Chris Lattner wrote: >>> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution >>> wrote: >>> I

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

> In an open source world, “closed by default” makes a lot more sense. That sounds Orwellian to me: War is Peace, Freedom is Slavery, Ignorance is Strength — and sealed is open?___ swift-evolution mailing list swift-evolution@swift.org

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

> On Jul 7, 2016, at 1:10 AM, Ricardo Parada via swift-evolution > wrote: > > In the motivation section performance is also mentioned as driving this > proposal. However I don't see any study that supports that. I would like to > see that. This should not be taken

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

I completely agree with rparada and give a strong, strong, strong -1 to this proposal. To make classes non-subclassable by default is only going to lead to unanticipated pain and frustration. Also agree with other comments that subclassable and overridable conflate access control with class

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

Sent from my iPad > On Jul 6, 2016, at 6:47 PM, Scott James Remnant wrote: > > >>> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >>> >>> To give you an example of the confusion, here is code made perfectly legal >>> by SE-0025: >>> >>>

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

Sent from my iPad > On Jul 6, 2016, at 6:39 PM, Scott James Remnant wrote: > > >> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >> >> Many of us believe “final” is too blunt a tool. There are many cases where >> final cannot be used but

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

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: >> >> To give you an example of the confusion, here is code made perfectly legal >> by SE-0025: >> >> public final class Example { >> >> overridable func foo() {} >> >> } > > I have no idea how you think

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

> On Jul 6, 2016, at 4:34 PM, Matthew Johnson wrote: > > Many of us believe “final” is too blunt a tool. There are many cases where > final cannot be used but you still don’t want external users subclassing or > overriding. > > We would like a more precise tool for

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

> On Jul 6, 2016, at 5:13 PM, Scott James Remnant wrote: > > >> On Jul 6, 2016, at 2:47 PM, Matthew Johnson > > wrote: >> >> This is not true. Public classes will *not* be “final by default”. It >> *will* be

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

> On Jul 5, 2016, at 7:11 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > >

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

> On Jul 6, 2016, at 2:47 PM, Matthew Johnson wrote: > > This is not true. Public classes will *not* be “final by default”. It > *will* be possible to subclass them within their declaring module. If they > need to be final they will still need to be marked as such.

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

> On Jul 6, 2016, at 4:36 PM, Scott James Remnant via swift-evolution > wrote: > > >> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa > > wrote: >> >> You can also try and simplify your outlines reducing X.c and X.d to a

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

I don't disagree with you on 'fileprivate' and 'private' being unnecessary and we may stick to the proposal at hand and leave the 'final' issue to another proposal, should anyone else care (I myself don't mind if it sticks around - just have to not use it). As for the conflict, I don't see it.

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

> On Jul 6, 2016, at 1:41 PM, Goffredo Marocchi via swift-evolution > wrote: > Sent from my iPhone > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> wrote: >> >> In the era of increased open sourcing, easy forking, and

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

> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa wrote: > > You can also try and simplify your outlines reducing X.c and X.d to a > single entry as it is the same rule applied to two different elements > of the language. Using one single keyword (such as in 'open') would > make

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

> On Jul 6, 2016, at 2:13 PM, Leonardo Pessoa wrote: > > So I did get what you meant right. Now tell me: if a class or method > is internal to your module (and you know internal means only you, > throught your source code, inside your app or library can extend it), > do you

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

> On Jul 6, 2016, at 3:41 PM, Goffredo Marocchi wrote: > >> On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution >> wrote: >> >> In the era of increased open sourcing, easy forking, and more >> community-driven development, this concern is

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

So I did get what you meant right. Now tell me: if a class or method is internal to your module (and you know internal means only you, throught your source code, inside your app or library can extend it), do you really need to mark anything as final for any reason? Final on any non-publics is a

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

Sent from my iPhone > On 6 Jul 2016, at 21:22, Paul Cantrell via swift-evolution > wrote: > > In the era of increased open sourcing, easy forking, and more > community-driven development, this concern is less severe than it used to be. > I rarely use any

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

> > On Jul 6, 2016, at 1:16 PM, Leonardo Pessoa wrote: > > Scott, I think your writing got a bit confuse but, if I got your > intention right, since you are the owner of the class, you may choose > to subclass it or not internally, no questions asked. No. This is how the

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

> * What is your evaluation of the proposal? +1, with bikeshedding. To me, “subclassable” does not imply “public.” If I hadn’t read this proposal, I would be likely to declare an internal class subclassable, and then be shocked when it was exposed as public! If it’s part of my public API, I

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

Scott, I think your writing got a bit confuse but, if I got your intention right, since you are the owner of the class, you may choose to subclass it or not internally, no questions asked. I need no finals in my apps and I only subclass if I intend to. If you are in control of your own code, why

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

> On Jul 6, 2016, at 12:50 PM, Leonardo Pessoa wrote: > > Scott, you really got a point here: should this proposal pass, I > believe the final keyword should be removed as it would be already the > default behaviour and thus unnecessary. I don't think this is on the >

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

Scott, you really got a point here: should this proposal pass, I believe the final keyword should be removed as it would be already the default behaviour and thus unnecessary. I don't think this is on the proposal. L On 6 July 2016 at 16:47, Scott James Remnant via swift-evolution

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

-1 This proposal makes Swift a more confusing language. Swift already has a mechanism for creating public subclassable classes and non-subclassable classes: public class SubclassableParentClass { } public final class NonSubclassableParentClass { } This mechanism also applies to methods,

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

> On Jul 5, 2016, at 9:11 PM, Kevin Lundberg wrote: > > I hadn't considered @testable, and it may be one way to mitigate the > trouble this could cause in tests, so thank you both for bringing it up > as the proposal should definitely account for it. I'm curious though how >

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

> On Jul 5, 2016, at 10:56 PM, Chris Lattner wrote: >> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution >> wrote: >> >>> >>> I think Kevin Lundberg is right to worry about testability, but I don't >>> think that has to prevent this

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

> On Jul 5, 2016, at 6:53 PM, John McCall via swift-evolution > wrote: > >> >> I think Kevin Lundberg is right to worry about testability, but I don't >> think that has to prevent this change. Instead, we should permit `@testable` >> imports to subclass/override

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

I hadn't considered @testable, and it may be one way to mitigate the trouble this could cause in tests, so thank you both for bringing it up as the proposal should definitely account for it. I'm curious though how this would solve the case of trying to subclass a module's class in a test where you

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

Sent from my iPad > On Jul 5, 2016, at 8:53 PM, John McCall via swift-evolution > wrote: > > >>> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>>* What is your evaluation of the proposal? >>

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

> On Jul 5, 2016, at 6:45 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > I think it's ultimately a good idea. Being noncommittal about > subclassability/overridability—and thus forbidding it in public

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

> * What is your evaluation of the proposal? I think it's ultimately a good idea. Being noncommittal about subclassability/overridability—and thus forbidding it in public scope, but not making any promises about what the module does internally—is the alternative that preserves the most

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

Extremely strong +1 from me on this proposal. It is the best default for many, many reasons (stated in the proposal and in Austin's review). It improves safety, facilitates and encourages reasoning about code, and will result in an ecosystem of overall higher quality. Sent from my iPad > On

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

+1 with modifications. In my team we write “final class” a lot. We also do have a lot of internal frameworks and an ability to guide external frameworks uses is important for us. We have a lot of candidates in our frameworks that should be inheritable internally, but we do not recommend to

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

I'll bite. On Tue, Jul 5, 2016 at 4:11 PM, Chris Lattner wrote: > > > * What is your evaluation of the proposal? > Strong +1. I like this proposal because it forces programmers vending a public API to think about their extension points, and it also provides