Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 22, 2015, at 1:31 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> UIKit classes aren't subclassable because of a lack of sealed-by-default, 
> they're subclassable because until very recently there was no way to mark 
> classes as not being subclassable. Many classes in UIKit are designed to 
> handle subclassing, but some classes are not designed to handle that, and are 
> explicitly documented as saying that you shouldn't subclass them because they 
> won't work right. Assuming a future in which UIKit is reimplemented in Swift, 
> every class today that is not explicitly documented as saying "don't subclass 
> this" would presumably be marked as inheritable. And the classes that say 
> "don't subclass this" may very well be final/sealed, and that's perfectly OK 
> because subclassing them doesn't work properly anyway.
> 
> Whether the language has final-by-default/sealed-by-default doesn't really 
> affect this in any way. I guarantee you that once Apple starts putting Swift 
> code in their frameworks, every single framework class Apple releases is 
> going to make an explicit decision about being final/sealed vs inheritable, 
> and the language defaults won't affect that one bit.
> 
> The only thing that final-by-default/sealed-by-default is going to affect is 
> third-party code that is released without carefully thinking about this 
> issue. And really, any code that is released that doesn't explicitly think 
> about this issue is likely to have issues with subclassing anyway (because 
> the developer didn't give any thought to whether subclasses would be allowed 
> and likely made assumptions in various places that it wouldn't, even if they 
> didn't consciously think about it). That said, I do think it's a really good 
> idea for anyone releasing libraries to make an explicit decision about 
> whether the class should be final/sealed or inheritable.
> 
> One benefit I haven't seen mentioned about this proposal is it makes it 
> obvious when the author has made an explicit decision. Today there's no 
> keyword for inheritable, so if a class doesn't say `final` you can't know if 
> that was explicit or implicit. But with this proposal, we'll have to gain an 
> `inheritable` keyword (and presumably a `sealed` keyword if we get sealed 
> behavior), which means every single class can be annotated with a keyword 
> indicating an explicit decision was made. Sure, people could still leave off 
> the keyword when they explicitly choose the default behavior, but we could 
> encourage a habit of always adding the keyword even if it's for the default 
> behavior just to indicate that this decision was intentional.
> 
> -Kevin Ballard

Thanks for this Kevin.  I have been trying to make these arguments throughout 
the thread but maybe haven’t been as eloquent as you are here.  The value of 
documenting the author's “statement of intent” and the value of knowing there 
cannot be any subclasses when no annotation exists should not be underestimated.

I’ve been following the thread very closely and have noticed six primary 
arguments against final by default:

1) Workarounds for framework “bugs”.  I put “bugs” in quotes because I think it 
is likely that sometimes it is not exactly a bug, but misunderstood or disliked 
behavior that is being “worked around".  No need to rehash this.  It’s been 
beaten to death.  It’s also irrelevant as it’s clear that the default is almost 
certainly going to be at least `sealed`.  It’s also irrelevant because Apple’s 
frameworks are currently written in Objective-C, not Swift, and when Apple 
begins writing frameworks in Swift they are very likely to be thinking 
carefully about subclassing as part of the API contract decision.

2) Flexibility.  If I don’t need inheritance when I first write a type and 
later realize I do need it, I have to revisit the type and add an `inheritable` 
annotation later.  This is closely related to argument #2 and mostly relevant 
during prototyping (argument #5).  IMO when this scenario arises you should 
have to revisit the original type.  If you don’t you are asking for trouble as 
inheritance was not considered when it was written.  Adding an `inheritable` 
annotation is trivial when compared to the analysis that should be performed 
when it becomes a superclass.

3) Annoyance.  Some consider it to be annoying to have to annotate a class 
declaration in order to inherit from it.  People stating this argument either 
are either writing a lot of superclasses or are so bothered by the need to 
annotate their type declarations that they avoid `final` and its related 
benefits when that is really the right thing for their class.  For me 
personally, `final` is the right thing for most classes I write.  I also think 
adding a `final` annotation is the right thing to do if you’re not sure whether 
it will be a superclass or not.  The need to modify the annotation will remind 
you that you haven’t fully 

Re: [swift-evolution] Final by default for classes and methods

[Stephen Celis via swift-evolution]

> On Dec 23, 2015, at 1:06 PM, Tino Heth <2...@gmx.de> wrote:
> 
>>> "If I don't want to subclass something, I just don't do it — why do I have 
>>> to change the properties of the superclass?"
>> 
>> Fix-its solve this with a single click.
> Really? I guess I like this alternate reality — can the Xcode in your 
> universe refactor Swift sources as well? ;-)

Swift fix-its are proliferous.

- Mutate a `let` and Xcode will let you change it to a `var`
- Mutate in a struct's `get` and Xcode will let you change it to be `mutating`
- I imagine that with this change: inherit from default `final` and Xcode will 
let you change it to be `inheritable`

Generally, all the above are questionable to solve for you with a single click, 
but at least you have the option ;)

I like `sealed` at the very least. But I'd be happy (maybe prefer?) `final` by 
default.

Stephen
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Craig Cruden via swift-evolution]

I thought sealed and final were effectively the same thing for production code, 
which is why it confuses me when you say final is right anything less including 
sealed is not.

In Scala at least sealed is final with the exception that subclasses within the 
same source file are allowed.  When it is compiled and shipped - you can no 
longer modify that source file….. 


> On 2015-12-24, at 1:36:01, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I strongly feel that I shouldn’t pay a price in production code in order to 
> better support those use cases.  IMO ‘final’ is the right default for 
> production code and we pay a price if the default is anything less, including 
> ‘sealed’. 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Michel Fortin via swift-evolution]

Le 23 déc. 2015 à 13:36, Matthew Johnson  a écrit :
> 
>> I'm not sure why you say the last two should be addressed separately from 
>> the "production" language. Are you proposing Swift should come in multiple 
>> language variants?
>> 
> 
> Not exactly. 
> 
> My point is that it is best to design the language to address production 
> concerns first.  If the defaults in that design cause problems for 
> prototyping and / or education it is possible to offer an environment with a 
> modified default.  I don’t know if that is a good idea or not.  I am not a 
> target user for either of those use cases (personally, I would rather 
> prototype with the production language).  Either way, it is possible, just as 
> it is possible to have @testable to facilitate unit testing.
> 
> I strongly feel that I shouldn’t pay a price in production code in order to 
> better support those use cases.  IMO ‘final’ is the right default for 
> production code and we pay a price if the default is anything less, including 
> ‘sealed’. 

By "pay a price" you mean diminished performance, right? That would depend on 
the ABI (which hasn't been discussed much yet, is there some preliminary docs 
about it?).

I don't think there is a price in performance to pay for sealed. You simply 
call a static function in the library, and that static function does the 
dynamic dispatch only if the library contains some overrides for that function. 
If there's no override it's simply purely a static call.

-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 23, 2015, at 12:59 PM, Stephen Celis  wrote:
> 
>> On Dec 23, 2015, at 1:55 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>>> By "pay a price" you mean diminished performance, right? That would depend 
>>> on the ABI (which hasn't been discussed much yet, is there some preliminary 
>>> docs about it?).
>>> 
>>> I don't think there is a price in performance to pay for sealed. You simply 
>>> call a static function in the library, and that static function does the 
>>> dynamic dispatch only if the library contains some overrides for that 
>>> function. If there's no override it's simply purely a static call.
>> 
>> No, I don’t mean performance.  I mean that the code is significantly less 
>> clear when final is not the default.  It isn’t clear at all whether the 
>> author intended to allow subclasses or not when the default allows 
>> inheritance.  The value in making this clear is significant, especially if 
>> you are a new developer walking into a large application.
> 
> While I agree with you, the same argument can be made for modules where 
> `internal` code isn't marked `private`. Existing access control makes a case 
> for `sealed` being the default, though I think class subclassing happens less 
> frequently, and thus could be made `final` by default and utilize fix-its to 
> make marking things inheritable simple enough.

I see the analogy, but IMO the issues involved in access control vs inheritance 
are significantly different.  I agree with the default of internal for access 
control.  However, I don’t want to get this thread sidetracked on the reasons 
why it is different and why I agree with that default.

Matthew

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Charles Srstka via swift-evolution]

> On Dec 23, 2015, at 1:12 PM, Felipe Cypriano via swift-evolution 
>  wrote:
> 
> On Wed, Dec 23, 2015, at 09:25, Tino Heth wrote:
>> 
>>> The benefits of it far out weight the fears of having it.
>> so what is the practical problem that's solved by final that convinced you?
> 
> I like to make those kind of questions to make people think about it
> with an open mind. Currently the way I'm seeing it, the arguments
> against it are mostly based on fear of change. It feeling that it could
> be applied to other things in Swift like strong types "I hate that can't
> just call this method on this AnyObject instance"; or access control "I
> can't just perform selector on a private method anymore”.

Or “I’ve had to work with other people’s C++ code before, and I know what a 
PITA it is when there’s an issue you could easily solve by subclassing and 
overriding a few methods, but the library author, lacking ESP and knowledge of 
the future, didn’t anticipate that use case.” Surely I can’t be the only one 
that’s happened to.

But don’t get me wrong, this proposal can work all right just as long as we get 
rid of all human developers from all library and framework projects, and hire 
God to do them instead. I wonder how much he charges?

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Michel Fortin via swift-evolution]

Le 23 déc. 2015 à 10:07, Matthew Johnson via swift-evolution 
 a écrit :
> 
> 3) Annoyance.  Some consider it to be annoying to have to annotate a class 
> declaration in order to inherit from it.  People stating this argument either 
> are either writing a lot of superclasses or are so bothered by the need to 
> annotate their type declarations that they avoid `final` and its related 
> benefits when that is really the right thing for their class.  For me 
> personally, `final` is the right thing for most classes I write.  I also 
> think adding a `final` annotation is the right thing to do if you’re not sure 
> whether it will be a superclass or not.  The need to modify the annotation 
> will remind you that you haven’t fully considered inheritance in your design 
> yet.
> 
> ...
> 
> 5) Prototyping.  This should also not influence the decision about what the 
> default is for production code.  I would not have a problem with a 
> prototyping environment allowing `inheritable` by default (maybe a Playground 
> mode?).  There could even be a tool that migrates the prototype to a real 
> project and adds the `inheritable` annotation where necessary.  Regardless of 
> what happens here, the prototyping problem can and should be solved 
> independently of the production language and should not influence the default 
> is used in and impacts production code.
> 
> 6) Education.  There may be some value in allowing inheritance by default in 
> education settings, especially early on.  I view this as being quite similar 
> to the prototyping case and again should not have an influence on the default 
> that professionals use in production code.

I think these three concerns would be addressed in good part by having sealed 
by default instead of `final`.

I'm not sure why you say the last two should be addressed separately from the 
"production" language. Are you proposing Swift should come in multiple language 
variants?

-- 
Michel Fortin
michel.for...@michelf.ca
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Felipe Cypriano via swift-evolution]

Sounds like you are going to continue using Objective-C until you can
get God on your team.


On Wed, Dec 23, 2015, at 11:23, Charles Srstka wrote:
>> On Dec 23, 2015, at 1:12 PM, Felipe Cypriano via swift-evolution > evolut...@swift.org> wrote:
>>
>> On Wed, Dec 23, 2015, at 09:25, Tino Heth wrote:
>>>
 The benefits of it far out weight the fears of having it.
>>> so what is the practical problem that's solved by final that
>>> convinced you?
>>
>> I like to make those kind of questions to make people think about it
>> with an open mind. Currently the way I'm seeing it, the arguments
>> against it are mostly based on fear of change. It feeling that it
>> could be applied to other things in Swift like strong types "I hate
>> that can't just call this method on this AnyObject instance"; or
>> access control "I can't just perform selector on a private method
>> anymore”.
> Or “I’ve had to work with other people’s C++ code before, and I know
> what a PITA it is when there’s an issue you could easily solve by
> subclassing and overriding a few methods, but the library author,
> lacking ESP and knowledge of the future, didn’t anticipate that use
> case.” Surely I can’t be the only one that’s happened to.
>
> But don’t get me wrong, this proposal can work all right just as long
> as we get rid of all human developers from all library and framework
> projects, and hire God to do them instead. I wonder how much he
> charges?
>
> Charles
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Felipe Cypriano via swift-evolution]

I can't speak for the others but I join the list as a skeptical of this 
proposal and in one day  I've embraced it. The benefits of it far out weight 
the fears of having it. 

I'd love to read it from the beginning but is kind of impossible. 

Felipe Cypriano

> On Dec 23, 2015, at 02:51, Tino Heth <2...@gmx.de> wrote:
> 
>> Isn't this proposal solving a problem that in practice doesn't exist or 
>> isn't common enough to be worth a language level fix? I'm trying to find an 
>> example of a common problem - in any language - that would benefit by having 
>> final/sealed by default.
> I guess you share that attitude with most developers that have not read the 
> full thread and never will do… and that is not meant as a suggestion to 
> review all those posts;-): I don't think there is anything that will make 
> someone change his opinion on this topic.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Felipe Cypriano via swift-evolution]

On Wed, Dec 23, 2015, at 09:25, Tino Heth wrote:
> 
>> The benefits of it far out weight the fears of having it.
> so what is the practical problem that's solved by final that convinced you?

I like to make those kind of questions to make people think about it
with an open mind. Currently the way I'm seeing it, the arguments
against it are mostly based on fear of change. It feeling that it could
be applied to other things in Swift like strong types "I hate that can't
just call this method on this AnyObject instance"; or access control "I
can't just perform selector on a private method anymore".

Mathew's summary has a list of 3 benefits of final by default that are
very compelling to me. I'm a strong believer that code should show its
author intention clearly, and not by just adding comments.

> 
> I also would change the list of downsides and put "annoyance" on top — 
> especially for those who don't care for theoretical improvement when they 
> have to pay the price in form of more effort:
> "If I don't want to subclass something, I just don't do it — why do I have to 
> change the properties of the superclass?"
> 
> Also:
> - structs are always final, inheritance is one of the major aspects of class. 
> In many cases, the decision for class is made because of the ability to 
> subclass.
> - you can't subclass across module borders with the default visibility
> In summary, final already is very common, and I don't see the need to push 
> this further just because "inheritance" became old-fashioned lately.
> 
> Best regards,
> Tino

Good point about structs being final. But on the other hand having
classes as final by default will make the difference between structs and
classes even simpler, the only difference by default would be value
semantics but classes could opt-in for openness.

About sealed vs final. I think this is a do or do not, sealed would just
complicate things by having different behavior depending on where the
code is. I'd go with final by default or not go at all.

---

One final thing, I came across this article about [Designed
Inheritance](http://martinfowler.com/bliki/DesignedInheritance.html) and
at the end the author mentions he would prefer a way to discourage
inheritance instead of prohibiting it. I'm intrigued by this idea and I
think I like it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Paul Cantrell via swift-evolution]

An omission in Matthey’s summary:



While tentatively supporting the proposal, some on the thread express a concern 
about its implications:

A shift toward more defensive programming in libraries prevents ad hoc 
workarounds in client projects. Clients of Objective-C libraries commonly work 
around bugs, shortcomings, and feature gaps with swizzling and dubious 
subclassing. These hacks, while undesirable in principle, are part of the 
current Apple development culture and ecosystem. Mechanisms that prevent such 
hacks, including but not limited to “final by default” or “sealed by default,” 
must be accompanied by a shift in how library authors think about their API 
design, and how they interact with their community. This shift will impose a 
new burden on library authors.

___

Matthew assures me off-list that this is distinct from his #1, which was meant 
only as a comment on Apple’s policies being independent of this proposal.

Cheers, P


> On Dec 23, 2015, at 9:07 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I’ve been following the thread very closely and have noticed six primary 
> arguments against final by default:
> 
> 1) Workarounds for framework “bugs”.  I put “bugs” in quotes because I think 
> it is likely that sometimes it is not exactly a bug, but misunderstood or 
> disliked behavior that is being “worked around".  No need to rehash this.  
> It’s been beaten to death.  It’s also irrelevant as it’s clear that the 
> default is almost certainly going to be at least `sealed`.  It’s also 
> irrelevant because Apple’s frameworks are currently written in Objective-C, 
> not Swift, and when Apple begins writing frameworks in Swift they are very 
> likely to be thinking carefully about subclassing as part of the API contract 
> decision.
> 
> 2) Flexibility.  If I don’t need inheritance when I first write a type and 
> later realize I do need it, I have to revisit the type and add an 
> `inheritable` annotation later.  This is closely related to argument #2 and 
> mostly relevant during prototyping (argument #5).  IMO when this scenario 
> arises you should have to revisit the original type.  If you don’t you are 
> asking for trouble as inheritance was not considered when it was written.  
> Adding an `inheritable` annotation is trivial when compared to the analysis 
> that should be performed when it becomes a superclass.
> 
> 3) Annoyance.  Some consider it to be annoying to have to annotate a class 
> declaration in order to inherit from it.  People stating this argument either 
> are either writing a lot of superclasses or are so bothered by the need to 
> annotate their type declarations that they avoid `final` and its related 
> benefits when that is really the right thing for their class.  For me 
> personally, `final` is the right thing for most classes I write.  I also 
> think adding a `final` annotation is the right thing to do if you’re not sure 
> whether it will be a superclass or not.  The need to modify the annotation 
> will remind you that you haven’t fully considered inheritance in your design 
> yet.
> 
> 4) Testing.  This is solvable with behavior similar to @testable.  It should 
> not influence the decision about what the default is for production code.
> 
> 5) Prototyping.  This should also not influence the decision about what the 
> default is for production code.  I would not have a problem with a 
> prototyping environment allowing `inheritable` by default (maybe a Playground 
> mode?).  There could even be a tool that migrates the prototype to a real 
> project and adds the `inheritable` annotation where necessary.  Regardless of 
> what happens here, the prototyping problem can and should be solved 
> independently of the production language and should not influence the default 
> is used in and impacts production code.
> 
> 6) Education.  There may be some value in allowing inheritance by default in 
> education settings, especially early on.  I view this as being quite similar 
> to the prototyping case and again should not have an influence on the default 
> that professionals use in production code.
> 
> If I have missed any of the major arguments against making `final` the 
> default please respond with them.  I would be happy to add them to the list.
> 
> I don’t find any of these arguments compelling.  The only one that is really 
> relevant to production code (once you accept the reality of #1) is annoyance 
> which I consider a minor complaint that is definitely not relevant to my code 
> and is likely not relevant to many other people’s code as well.  
> 
> On the other hand, the argument for `final` as default is compelling IMHO.  
> As has been stated many times, inheritance is part of an API contract that 
> needs to be considered as clearly as anything else.  This still applies when 
> the API is internal to an app.
> 
> Final by default greatly improves our ability to get up to speed on a new 
> codebase 

Re: [swift-evolution] Final by default for classes and methods

[Stephen Celis via swift-evolution]

> On Dec 23, 2015, at 12:25 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> I also would change the list of downsides and put "annoyance" on top — 
> especially for those who don't care for theoretical improvement when they 
> have to pay the price in form of more effort:
> "If I don't want to subclass something, I just don't do it — why do I have to 
> change the properties of the superclass?"

Fix-its solve this with a single click.

Stephen
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 23, 2015, at 12:26 PM, Michel Fortin  wrote:
> 
> Le 23 déc. 2015 à 10:07, Matthew Johnson via swift-evolution 
> > a écrit :
>> 
>> 3) Annoyance.  Some consider it to be annoying to have to annotate a class 
>> declaration in order to inherit from it.  People stating this argument 
>> either are either writing a lot of superclasses or are so bothered by the 
>> need to annotate their type declarations that they avoid `final` and its 
>> related benefits when that is really the right thing for their class.  For 
>> me personally, `final` is the right thing for most classes I write.  I also 
>> think adding a `final` annotation is the right thing to do if you’re not 
>> sure whether it will be a superclass or not.  The need to modify the 
>> annotation will remind you that you haven’t fully considered inheritance in 
>> your design yet.
>> 
>> ...
>> 
>> 5) Prototyping.  This should also not influence the decision about what the 
>> default is for production code.  I would not have a problem with a 
>> prototyping environment allowing `inheritable` by default (maybe a 
>> Playground mode?).  There could even be a tool that migrates the prototype 
>> to a real project and adds the `inheritable` annotation where necessary.  
>> Regardless of what happens here, the prototyping problem can and should be 
>> solved independently of the production language and should not influence the 
>> default is used in and impacts production code.
>> 
>> 6) Education.  There may be some value in allowing inheritance by default in 
>> education settings, especially early on.  I view this as being quite similar 
>> to the prototyping case and again should not have an influence on the 
>> default that professionals use in production code.
> 
> I think these three concerns would be addressed in good part by having sealed 
> by default instead of `final`.
> 
> I'm not sure why you say the last two should be addressed separately from the 
> "production" language. Are you proposing Swift should come in multiple 
> language variants?
> 

Not exactly. 

My point is that it is best to design the language to address production 
concerns first.  If the defaults in that design cause problems for prototyping 
and / or education it is possible to offer an environment with a modified 
default.  I don’t know if that is a good idea or not.  I am not a target user 
for either of those use cases (personally, I would rather prototype with the 
production language).  Either way, it is possible, just as it is possible to 
have @testable to facilitate unit testing.

I strongly feel that I shouldn’t pay a price in production code in order to 
better support those use cases.  IMO ‘final’ is the right default for 
production code and we pay a price if the default is anything less, including 
‘sealed’. 

Matthew___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Craig Cruden via swift-evolution]

The “module” in this case being the same source file.

i.e.  Family.scala  

contains a sealed class called “Parent” which is sealed, 

you could have another class in their called “Child” which inherits from the 
parent.  

but you cannot write another class and inherit from it in Sibling.scala.

Since only the library writer has access to Family.scala and the classes are 
sealed by default - it is effectively the same as final by default other than 
it does not restrict the actual writer of the library not to inherit from their 
own class.


> On 2015-12-24, at 1:45:45, Matthew Johnson  wrote:
> 
> 
>> On Dec 23, 2015, at 12:43 PM, Craig Cruden > > wrote:
>> 
>> I thought sealed and final were effectively the same thing for production 
>> code, which is why it confuses me when you say final is right anything less 
>> including sealed is not.
>> 
>> In Scala at least sealed is final with the exception that subclasses within 
>> the same source file are allowed.  When it is compiled and shipped - you can 
>> no longer modify that source file….. 
> 
> They are not at all the same.  The difference is that with sealed you cannot 
> inherit from classes in other modules which are not explicitly marked 
> `inheritable`, but you can inherit from classes in your own module that are 
> not explicitly marked `inheritable`.  That is a big difference.
> 
>> 
>> 
>>> On 2015-12-24, at 1:36:01, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> I strongly feel that I shouldn’t pay a price in production code in order to 
>>> better support those use cases.  IMO ‘final’ is the right default for 
>>> production code and we pay a price if the default is anything less, 
>>> including ‘sealed’. 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

> The benefits of it far out weight the fears of having it.
so what is the practical problem that's solved by final that convinced you?

I also would change the list of downsides and put "annoyance" on top — 
especially for those who don't care for theoretical improvement when they have 
to pay the price in form of more effort:
"If I don't want to subclass something, I just don't do it — why do I have to 
change the properties of the superclass?"

Also:
- structs are always final, inheritance is one of the major aspects of class. 
In many cases, the decision for class is made because of the ability to 
subclass.
- you can't subclass across module borders with the default visibility
In summary, final already is very common, and I don't see the need to push this 
further just because "inheritance" became old-fashioned lately.

Best regards,
Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

>> "If I don't want to subclass something, I just don't do it — why do I have 
>> to change the properties of the superclass?"
> 
> Fix-its solve this with a single click.
Really? I guess I like this alternate reality — can the Xcode in your universe 
refactor Swift sources as well? ;-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Charles Srstka via swift-evolution]

The frameworks remaining useful simply because they happen to be written in a 
different language would be a pretty sad state of affairs, IMO.

Charles

> On Dec 23, 2015, at 1:30 PM, Felipe Cypriano  wrote:
> 
> Sounds like you are going to continue using Objective-C until you can get God 
> on your team.
>  
>  
> On Wed, Dec 23, 2015, at 11:23, Charles Srstka wrote:
>>> On Dec 23, 2015, at 1:12 PM, Felipe Cypriano via swift-evolution 
>>> > wrote:
>>>  
>>> On Wed, Dec 23, 2015, at 09:25, Tino Heth wrote:
  
> The benefits of it far out weight the fears of having it.
 so what is the practical problem that's solved by final that convinced you?
>>>  
>>> I like to make those kind of questions to make people think about it
>>> with an open mind. Currently the way I'm seeing it, the arguments
>>> against it are mostly based on fear of change. It feeling that it could
>>> be applied to other things in Swift like strong types "I hate that can't
>>> just call this method on this AnyObject instance"; or access control "I
>>> can't just perform selector on a private method anymore”.
>> 
>> Or “I’ve had to work with other people’s C++ code before, and I know what a 
>> PITA it is when there’s an issue you could easily solve by subclassing and 
>> overriding a few methods, but the library author, lacking ESP and knowledge 
>> of the future, didn’t anticipate that use case.” Surely I can’t be the only 
>> one that’s happened to.
>>  
>> But don’t get me wrong, this proposal can work all right just as long as we 
>> get rid of all human developers from all library and framework projects, and 
>> hire God to do them instead. I wonder how much he charges?
>>  
>> Charles
>>  
>  

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

Sent from my iPhone

> On Dec 23, 2015, at 2:28 PM, Felipe Cypriano via swift-evolution 
>  wrote:
> 
>> On Wed, Dec 23, 2015, at 11:12, Felipe Cypriano wrote:
>> About sealed vs final. I think this is a do or do not, sealed would just
>> complicate things by having different behavior depending on where the
>> code is. I'd go with final by default or not go at all.
>  
> I changed my mind about sealed being a bad thing, this email from [John 
> McCall](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001032.html)
>  has very good points.
>  
> ---
>  
> Also I just noticed that this thread title mentions methods as final by 
> default, but I can't find an example/proposal of how it would work. My 
> question is is anyone suggesting that methods must be marked as "overridable" 
> even if the class is inheritable? E.g:

The original post did indeed have that intention.  However, pretty much the 
entire thread has been focused exclusively on classes, not methods.  That has 
turned out to be a plenty big can of worms on its own.

I think it's best to keep this thread focused on classes.  We can start a new 
thread for methods later if desired.  But we should wait until the dust has 
settled on the classes conversation IMO.


>  
> ```
> open class Money {
> func vanish() {
> }
> }
> ```
>  
> Is `vanish` final?
>  
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Austin Zheng via swift-evolution]

Responses inline. 

On Dec 23, 2015, at 12:35 PM, Brent Royal-Gordon  wrote:

>> If the frameworks are written in Swift, nothing is stopping Apple from 
>> slapping 'final' on all the classes they don't want developers to inherit 
>> from, even if the proposal is rejected; neither is there anything stopping 
>> them from making all their classes inheritable (if that happened to be what 
>> they wanted, which it isn't).
> 
> You cannot look at a language simply as a technical artifact. A language 
> creates culture and shapes the systems written in it. It defines not only 
> what is possible and what is not, but also what is preferred and what is 
> discouraged. Defaults matter. If they didn't, people wouldn't be trying to 
> change the default.

You're right that defaults matter, but that's not the point. The argument is 
that this proposal is bad because it will make future Apple frameworks less 
flexible than if nothing were done. I'm saying that's not the case; if Apple 
wants to write frameworks in Swift then they will most likely annotate their 
APIs however they want, whether with 'final' or 'inheritable' or whatever their 
internal policy on this matter is, regardless of whether this proposal is 
adopted. They already make intended usage clear in the documentation.

> Making `final` the default, or `sealed` the default, encourages the use of 
> closed class hierarchies. It attempts to make inflexibility the preferred 
> form of shared Swift code. I'm not sure that's the right thing to do.
> 

Protocols are a more general and arguably superior way of making shared code 
flexible. I understand and sympathize with the flexibility argument but I think 
pushing for better abstractions is worth it (and I understand why others 
disagree).

> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 23, 2015, at 8:43 PM, Charles Srstka  wrote:
> 
>> On Dec 23, 2015, at 8:15 PM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> I’m not trying to force my opinion on anyone.  I’m just making a case for 
>> the advantages of a particular default.  Changing the default does not break 
>> inheritance at all.  Nobody has to use the default when it doesn’t fit the 
>> design they wish to implement.  
> 
> I disagree; changing the default will largely break inheritance, because 
> hardly anything (in pure-Swift frameworks; I know that Obj-C will still be 
> what it is) will be overridable anymore, unless the framework author 
> specifically anticipated your use case. Which when we’re dealing with human 
> developers, isn’t necessarily going to be the case.
> 

Please read the post I just sent regarding 3rd party frameworks and libraries 
and comment there if you disagree.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Andrey Tarantsov via swift-evolution]

> Isn't this proposal solving a problem that in practice doesn't exist or isn't 
> common enough to be worth a language level fix?

Well I have a TextExpander macro that inserts "// override point" when I type 
;overp. Been marking all overridable methods this way for years. I think it's 
an indication that the problem is worth solving.

> I'm trying to find an example of a common problem - in any language - that 
> would benefit by having final/sealed by default.

Understanding the code and reasoning about the class is easier when you know 
the exact customization points.

I do agree that this won't really prevent many actual bugs.

A.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 23, 2015, at 3:21 PM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> I think it's best to keep this thread focused on classes.  We can start a 
>> new thread for methods later if desired.  But we should wait until the dust 
>> has settled on the classes conversation IMO.
> I disagree: The whole thread is not about practical implications but rather 
> about general standpoints, so the discussion will be identical — and I 
> foresee that this second thread would start with "now that we made classes 
> final by default, it's just natural consequence to do the same with methods".
> 
>>> Making `final` the default, or `sealed` the default, encourages the use of 
>>> closed class hierarchies. It attempts to make inflexibility the preferred 
>>> form of shared Swift code. I'm not sure that's the right thing to do.
>>> 
>> I don't agree with this framing.  IMO it encourages alternative designs 
>> emphasizing protocols and composition.  This is a very good thing IMHO.  I 
>> like to think of inheritance is a tool is last resort. 
> 
> The claim about inflexibility is to take with a grain of salt, but why do you 
> think it is good to force your opinion on how flexibility should be achieved 
> on others? Protocols and composition are useful without breaking inheritance, 
> just leave the choice to the people.

I’m not trying to force my opinion on anyone.  I’m just making a case for the 
advantages of a particular default.  Changing the default does not break 
inheritance at all.  Nobody has to use the default when it doesn’t fit the 
design they wish to implement.  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 23, 2015, at 11:36 AM, Paul Cantrell  wrote:
> 
> An omission in Matthey’s summary:
> 
> 
> 
> While tentatively supporting the proposal, some on the thread express a 
> concern about its implications:
> 
> A shift toward more defensive programming in libraries prevents ad hoc 
> workarounds in client projects. Clients of Objective-C libraries commonly 
> work around bugs, shortcomings, and feature gaps with swizzling and dubious 
> subclassing. These hacks, while undesirable in principle, are part of the 
> current Apple development culture and ecosystem. Mechanisms that prevent such 
> hacks, including but not limited to “final by default” or “sealed by 
> default,” must be accompanied by a shift in how library authors think about 
> their API design, and how they interact with their community. This shift will 
> impose a new burden on library authors.
> 
> ___
> 
> Matthew assures me off-list that this is distinct from his #1, which was 
> meant only as a comment on Apple’s policies being independent of this 
> proposal.
> 

I want to thank Paul for pointing out an omission in the list I posted this 
morning.  As Paul mentions the first item on my list was focused on Apple 
frameworks and the fact that Swift’s default doesn’t prevent Apple from 
adopting a policy of making explicit design decisions regarding inheritability 
of their framework classes.

Paul points out that many people have similar concerns about how the default 
might impact 3rd party frameworks and libraries.  In 2015 this usually means 
open source libraries.  

I think it is worth repeating an important point that has been stated many 
times by many individuals in this thread: a responsible library author 
considers inheritability as part of the API contract.  If they have not planned 
for it they should not allow it.  This is true regardless of what the default 
of the language is and whether the framework is from Apple or an open source 
library.

That said, if a developer runs into an issue with an open source library that 
has a final class they would like to subclass there are several options 
available:

1. If the need to subclass is due to a bug, file a bug report or fix it and 
contribute a patch.  No subclassing necessary.
2. If you view the `final` status as a design error get in touch with the 
authors and discuss an enhancement.
3. If the authors agree in theory, but don’t want to do the implementation work 
of designing a proper superclass, do the work yourself and make a contribution.
4. If the authors disagree they would probably be using final if it wasn’t the 
default.  You can still fork the project and make any changes you desire, 
including allowing inheritance.  You can even allow inheritance without really 
thinking about whether the superclass is properly designed to support it or not 
if you really want to.  Nobody is stopping you or limiting your flexibility 
when it comes to open source projects!

In reality closed source, binary only libraries from 3rd parties are the 
exception, not the norm.  Bad experiences with closed source, binary libraries 
(some have mentioned C++) in the past aren’t really applicable to future 
experiences with open source libraries.

Of course closed source libraries do still exist, usually in the form of an SDK 
for a third party service.  I wonder how many of those expressing the concern 
about 3rd party libraries are referring to SDKs like this, and if they are, 
what kinds of issues have been encountered in the past that are motivating the 
concern.  If this is what people are worried about it might help the 
conversation if you are able to get a little bit more specific with your 
concerns.

Matthew


> 
>> On Dec 23, 2015, at 9:07 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> I’ve been following the thread very closely and have noticed six primary 
>> arguments against final by default:
>> 
>> 1) Workarounds for framework “bugs”.  I put “bugs” in quotes because I think 
>> it is likely that sometimes it is not exactly a bug, but misunderstood or 
>> disliked behavior that is being “worked around".  No need to rehash this.  
>> It’s been beaten to death.  It’s also irrelevant as it’s clear that the 
>> default is almost certainly going to be at least `sealed`.  It’s also 
>> irrelevant because Apple’s frameworks are currently written in Objective-C, 
>> not Swift, and when Apple begins writing frameworks in Swift they are very 
>> likely to be thinking carefully about subclassing as part of the API 
>> contract decision.
>> 
>> 2) Flexibility.  If I don’t need inheritance when I first write a type and 
>> later realize I do need it, I have to revisit the type and add an 
>> `inheritable` annotation later.  This is closely related to argument #2 and 
>> mostly relevant during prototyping (argument #5).  IMO when this scenario 
>> arises you should have to revisit the 

Re: [swift-evolution] Final by default for classes and methods

[Charles Srstka via swift-evolution]

> On Dec 23, 2015, at 8:15 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> I’m not trying to force my opinion on anyone.  I’m just making a case for the 
> advantages of a particular default.  Changing the default does not break 
> inheritance at all.  Nobody has to use the default when it doesn’t fit the 
> design they wish to implement. 

I disagree; changing the default will largely break inheritance, because hardly 
anything (in pure-Swift frameworks; I know that Obj-C will still be what it is) 
will be overridable anymore, unless the framework author specifically 
anticipated your use case. Which when we’re dealing with human developers, 
isn’t necessarily going to be the case.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Andrey Tarantsov via swift-evolution]

> Aren't we mixing up two different issues here? "Having a default final for 
> Swift classes" should be treated as a separate issue from "Apple frameworks 
> should stay overridable".

I have to agree, and so I'll change my vote to +1.

>  1. Within a module, should I be able to override my own classes / methods by 
> default, or should I have to explicitly mark those classes as overridable to 
> do that?

Definitely not — explicit is preferred, mostly for documentation purposes (I 
don't think there's much safety to be gained within your own module). Perhaps 
because in my code, overridable methods are perhaps 1% of all.

>  2. If I'm releasing a Swift binary framework, and I haven't yet thought 
> about which classes / methods should be overrideable, should I release it in 
>  everything-is-overridable mode, or in nothing-is-overridable mode?

That's a tricky one. Ideally you would pretend that nothing is overridable, but 
some hack like @testable makes everything overridable when really needed.

>  3. If I'm using a third-party (non-Apple) Swift binary framework, and if the 
> framework author hadn't really thought about which classes / methods should 
> be overrideable, would I want the power to override everything in the 
> framework now?

Yes. There were many cases where fixing up a pod was just an important as 
fixing up an Apple framework.

Yes, I have an option to change the source — but it's vastly more 
labour-intensive if all you need is a simple isolated change. (Especially if 
that change isn't likely to be accepted upstream.)

> (Note that if I get that power, I forgo all hope of getting a 
> binary-compatible update to the framework with correct annotations about 
> which classes can be safely overridden and which aren't meant to be 
> overridden.)

Sure, and that doesn't matter because all frameworks are built with your app 
anyway.

>  A3: Ideally, I'd like to be able to override everything in the framework I 
> use, but if that implies that I can't get a binary-compatible fix to the 
> framework, maybe I can live without that overridability.

Why would you want binary compatibility for non-Apple frameworks? It's not like 
you can install them globally (or would want to, even if you could).

A.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Felipe Cypriano via swift-evolution]

Am 23.12.2015 um 20:12 schrieb Felipe Cypriano :
>>
>>> so what is the practical problem that's solved by final that
>>> convinced you?
>>
>> I like to make those kind of questions to make people think about it
>> with an open mind.
>
> So no real problems at all? Just a rhetorical trick? I won't comment
> on this but leave the interpretation to the closed-minded...

Not at all, its intent is to facilitate reasoning from first principles.
Google it if you are interested.

I kinda explained myself way more than that little sentence and you
decided to ignore everything and focus on "I'm ignoring the answer
because it suits me", which is fine by me just wanted to point it out.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

>> 5) Prototyping.  This should also not influence the decision about what the 
>> default is for production code.  I would not have a problem with a 
>> prototyping environment allowing `inheritable` by default (maybe a 
>> Playground mode?).  There could even be a tool that migrates the prototype 
>> to a real project and adds the `inheritable` annotation where necessary.  
>> Regardless of what happens here, the prototyping problem can and should be 
>> solved independently of the production language and should not influence the 
>> default is used in and impacts production code.

Now, that offers an easy way out: Just assume that Swift stays in 
prototype-mode (nothing lasts as long as a prototype) and write that migration 
tool to annotate each class with final — problem solved, everyone is happy.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Brent Royal-Gordon via swift-evolution]

> If the frameworks are written in Swift, nothing is stopping Apple from 
> slapping 'final' on all the classes they don't want developers to inherit 
> from, even if the proposal is rejected; neither is there anything stopping 
> them from making all their classes inheritable (if that happened to be what 
> they wanted, which it isn't).

You cannot look at a language simply as a technical artifact. A language 
creates culture and shapes the systems written in it. It defines not only what 
is possible and what is not, but also what is preferred and what is 
discouraged. Defaults matter. If they didn't, people wouldn't be trying to 
change the default.

Making `final` the default, or `sealed` the default, encourages the use of 
closed class hierarchies. It attempts to make inflexibility the preferred form 
of shared Swift code. I'm not sure that's the right thing to do.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

> I think it's best to keep this thread focused on classes.  We can start a new 
> thread for methods later if desired.  But we should wait until the dust has 
> settled on the classes conversation IMO.
I disagree: The whole thread is not about practical implications but rather 
about general standpoints, so the discussion will be identical — and I foresee 
that this second thread would start with "now that we made classes final by 
default, it's just natural consequence to do the same with methods".

>> Making `final` the default, or `sealed` the default, encourages the use of 
>> closed class hierarchies. It attempts to make inflexibility the preferred 
>> form of shared Swift code. I'm not sure that's the right thing to do.
>> 
> I don't agree with this framing.  IMO it encourages alternative designs 
> emphasizing protocols and composition.  This is a very good thing IMHO.  I 
> like to think of inheritance is a tool is last resort. 

The claim about inflexibility is to take with a grain of salt, but why do you 
think it is good to force your opinion on how flexibility should be achieved on 
others? Protocols and composition are useful without breaking inheritance, just 
leave the choice to the people.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Felipe Cypriano via swift-evolution]

On Wed, Dec 23, 2015, at 20:09, Andrey Tarantsov wrote:
>> Isn't this proposal solving a problem that in practice doesn't exist
>> or isn't common enough to be worth a language level fix?
>
> Well I have a TextExpander macro that inserts "// override point" when
> I type ;overp. Been marking all overridable methods this way for
> years. I think it's an indication that the problem is worth solving.
>
>> I'm trying to find an example of a common problem - in any language -
>> that would benefit by having final/sealed by default.
>
> Understanding the code and reasoning about the class is easier when
> you know the exact customization points.
>
> I do agree that this won't really prevent many actual bugs.
>
> A.
>
Those are good points and things I came to realize after I asked that. I
don't have a Text Expander snippet but it is common in the code I work
to have some kind of hack to inform what is intended to be overrided.

Thanks for sharing, this is exactly the kind of answer (not because it
is in favor of final) I was hoping to get when I asked.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Dave Abrahams via swift-evolution]

> On Dec 22, 2015, at 9:03 AM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> Joe’s and Brent’s writeups copied below really get to the heart of this for 
> me. This is a tough question, and I find myself torn. I’m sympathetic to both 
> lines of argument.
> 
> It’s not entirely true that “you can never take back” overridability — you 
> can make a breaking API change with a new major version, of course — but it’s 
> a compelling point nonetheless. One default is clearly safer than the other, 
> at least for the library author. “Safe by default” is indeed the Swift MO. 
> (Well, except for array subscripting. And any public API involving tuples, 
> for which any change, even type widening, is a breaking change. And….OK, it’s 
> not absolute, but “safe by default” is the MO 95% of the time.) “Final by 
> default” just seems more Swift-like to me.
> 
> Despite that, Joe, I have to agree with Brent on his central point: the 
> perspective that comes from spending a lot of time _writing_ libraries is 
> very different from one who spend more time _using_ them. Yes, UIKit is not 
> going to be rewritten in Swift anytime soon, but Brent is rightly imagining a 
> future where the Swift way is The Way.
> 
> I weigh the safety argument against the many long hours I’ve spent beating my 
> head against library behaviors, wishing I could read UIKit’s source code, 
> wishing I could tweak that one little thing that I can’t control, and being 
> grateful for the dubious workaround that saves the day — yes, even when a 
> subsequent OS update breaks it. I know what I’m getting into when I solve a 
> problem with a hack, and if the hack ships, it’s only because I weighed the 
> risks and benefits. We app developers rely on swizzling, dubious subclassing, 
> and (especially) undocumented behavior far more often than any of us would 
> like. It is just part of the reality of making things ship — and an important 
> part of the success of Apple’s app ecosystem.

The same argument implies that we never should have created Swift as it is; 
that leaving everything dynamic everywhere is necessary so people can get their 
work done.  In some ways it’s a self-fulfilling prophecy.  I once knew a 
programmer that argued that all properties/ivars should be public, in case you 
need to go in and work around some problem.  Naturally, he “needed" to take 
advantage of that public exposure all the time.  I predict that, as Swift does 
more to disallow unintended effects, you’ll start to see fewer and fewer of the 
kinds of problem that require these dubious workarounds.

> This debate reminds me of something that often happens when a 
> humans-and-paper process moves to software. When the software starts 
> rigorously enforcing all the rules the humans were theoretically following 
> all along, and it turns out that quite a lot of in-the-moment nuanced human 
> judgement was crucial to making everything work. With nuance removed, things 
> fall apart — and instead of things at last achieving the rigor that seemed so 
> desirable in theory, the process has to explicitly loosen. (At the local 
> coffee shop, a new iPad-based POS system suddenly made it an “uh let me get 
> the manager” moment when I want to get the off-menu half-sized oatmeal I’ve 
> always got for my toddler.)
> 
> I’m not totally opposed to final by default. Joe’s arguments sway me in 
> principle. In practice, if Swift does indeed moves us toward “less wiggle 
> room, less hackable” by default, then that wiggle room _will_ have to come 
> from somewhere else: perhaps more open sourcing and more forking, or faster 
> turnaround on fixes from library authors, or a larger portion of time spent 
> by library authors explicitly exposing and documenting customization points. 
> The new effort involved for library authors is nothing to sneeze at.

No, it’s nothing to sneeze at; it is essential for creating reliable software.  
As a library author, I support anything that helps produce that level of care 
:-)

> Cheers,
> 
> Paul
> 
> 
>> On Dec 22, 2015, at 9:46 AM, Joe Groff via swift-evolution 
>>  wrote:
>> 
>> I think a lot of people in this thread are conflating "final by default" or 
>> "sealed by default" with "sealed everywhere". No matter what the default is, 
>> the frameworks aren't going to suddenly rewrite themselves in Swift with 
>> final everything; Objective-C will still be what it is. Furthermore, we're 
>> only talking about language defaults; we're not taking away the ability for 
>> frameworks to make their classes publicly subclassable or dynamically 
>> overrideable. That's a policy decision for framework authors to make. The 
>> goal of "sealed by default" is to make sure the language doesn't make 
>> promises on the developer's behalf that they weren't ready to keep. ObjC's 
>> flexibility is valuable, and Apple definitely takes advantage of it 
>> internally all over place; Apple also has an 

Re: [swift-evolution] Final by default for classes and methods

[Drew Crawford via swift-evolution]

> On Dec 22, 2015, at 11:03 AM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> I’m not totally opposed to final by default. Joe’s arguments sway me in 
> principle. In practice, if Swift does indeed moves us toward “less wiggle 
> room, less hackable” by default, then that wiggle room _will_ have to come 
> from somewhere else: perhaps more open sourcing and more forking, or faster 
> turnaround on fixes from library authors, or a larger portion of time spent 
> by library authors explicitly exposing and documenting customization points. 
> The new effort involved for library authors is nothing to sneeze at.

> On Dec 21, 2015, at 11:50 AM, Jordan Rose via swift-evolution 
> > wrote:

> Of course Apple code will have bugs in it. Trying to patch over these bugs in 
> your own code is (1) obviously not an answer Apple would support, but also 
> (2) fraught with peril, and (3) likely to break in the next OS release.
> 
> TLDR: It's already unsafe to do this with the existing set of Swift features. 
> Yes, this makes things "worse", but it's not something we're interested in 
> supporting anyway.

I actually agree with making final default.  But I think it's important to 
understand the consequence.  "One does not simply" seal all the classes.

I'm going to repeat publicly something that third-party developers (including 
me) have been talking about privately for over a year.  We're going to end up 
moving to open-source, community-maintained frameworks (a la 
swift-corelibs-foundation), and away from closed-source Apple-maintained 
dependencies.

This isn't the place to rehash the whole tired history of it, but to provide a 
little context: I alone have 217 open, non-duplicated radars under my main 
account.  That is a lot of radars.  The problem resolution strategies available 
to third-party developers are very very bad.  Subclassing is one of those "bad" 
resolution strategies that everybody agrees is awful, but what are you going to 
do, rewrite the core Apple frameworks by yourself?

Yes, as it turns out.  Many of us were pleasantly surprised (and some of us 
literally could not believe) Apple's support for this effort with 
swift-corelibs-foundation.  But I think (some) on this list may be unprepared 
for the full extent to which the community will be taking on an active role.  I 
actually have a whole queue of patches in the basement that predate 
swift-corelibs-foundation completely that I will be sending upstream slowly, 
and what gets rejected will be third-partied somewhere.  That's before we even 
get to the question of replacing some of the other technologies that don't 
appear on github.com/apple .  

IMO making the transition to "open" frameworks that we can actually 
fork/fix/bundle ourselves is the Right Solution™ to this whole "final" debate, 
but I think it is important to preview for everybody involved that this is the 
straw on a very overworked camel.  I had to subclass UIKit yet again just a few 
days ago.  Paul Cantrell is 100% right that the wiggle room will have to come 
from somewhere. 

The wiggle room will come from the community stepping up and making our own 
tools.  That has been happening to some extent in the dark, but presently it 
will be happening in the daylight.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Greg Parker via swift-evolution]

> On Dec 22, 2015, at 11:31 AM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> UIKit classes aren't subclassable because of a lack of sealed-by-default, 
> they're subclassable because until very recently there was no way to mark 
> classes as not being subclassable.

There are two historical ways to disallow subclassing of public classes.
1. Perform an isa check in your -init method and halt if it's not your class. 
Attempts to subclass will get runtime errors.
2. Mark your class's metaclass symbol as un-exported. Attempts to subclass will 
get link-time errors.

Both are used but neither is common.


> Whether the language has final-by-default/sealed-by-default doesn't really 
> affect this in any way. I guarantee you that once Apple starts putting Swift 
> code in their frameworks, every single framework class Apple releases is 
> going to make an explicit decision about being final/sealed vs inheritable, 
> and the language defaults won't affect that one bit.

You may be overestimating Apple's engineers. We're just developers too. 
Whatever the default is, it will be incorrectly left in place more often than 
you'd like.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Rod Brown via swift-evolution]

It comes down to a few issues:

1. Final exists in the language. This itself creates headaches for framework 
makers when their framework classes need to become “final” at a later stage. 
What do you do with the old subclasses in an app that shipped 5 years ago 
subclassing a now-final class?

2. Many believe that you should only subclass classes designed to be 
subclassed, due to safety concerns. This means that the onus should be on the 
developer to put it in, rather than assume it’s subclassable.

3. Many other developers wonder about whether that is wise when we, especially 
some of us iOS devs, create subclasses of classes that were not designed to be 
subclassed, and we view our reasons for doing so as legitimate as part of the 
creative process of breaking out of the assumed constraints of the standard 
class.

4. Performance improvements can be made if you know a class is final. Swift, 
attempting to be as performant as possible, can optimise if it knows everything 
in the list will be of a certain type, and can optimise further if it knows 
that it will be *exactly* a type, rather than potentially a subclass.

I think there have been a few discussed, but this is a summation.


> On 23 Dec 2015, at 10:45 AM, Felipe Cypriano via swift-evolution 
>  wrote:
> 
> I could read the entire conversation because following the web archives is 
> super unintuitive. So feel free to answer me with a bunch of links if you 
> think my question was already answered.
> 
> Isn't this proposal solving a problem that in practice doesn't exist or isn't 
> common enough to be worth a language level fix? I'm trying to find an example 
> of a common problem - in any language - that would benefit by having 
> final/sealed by default.
> 
> ---
> Felipe Cypriano
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Paul Cantrell via swift-evolution]

> On Dec 22, 2015, at 6:24 PM, Dave Abrahams  wrote:
> 
>> On Dec 22, 2015, at 9:03 AM, Paul Cantrell via swift-evolution 
>>  wrote:
>> 
>> I weigh the safety argument against the many long hours I’ve spent beating 
>> my head against library behaviors, wishing I could read UIKit’s source code, 
>> wishing I could tweak that one little thing that I can’t control, and being 
>> grateful for the dubious workaround that saves the day — yes, even when a 
>> subsequent OS update breaks it. I know what I’m getting into when I solve a 
>> problem with a hack, and if the hack ships, it’s only because I weighed the 
>> risks and benefits. We app developers rely on swizzling, dubious 
>> subclassing, and (especially) undocumented behavior far more often than any 
>> of us would like. It is just part of the reality of making things ship — and 
>> an important part of the success of Apple’s app ecosystem.
> 
> The same argument implies that we never should have created Swift as it is; 
> that leaving everything dynamic everywhere is necessary so people can get 
> their work done.  In some ways it’s a self-fulfilling prophecy.  I once knew 
> a programmer that argued that all properties/ivars should be public, in case 
> you need to go in and work around some problem.  Naturally, he “needed" to 
> take advantage of that public exposure all the time.  I predict that, as 
> Swift does more to disallow unintended effects, you’ll start to see fewer and 
> fewer of the kinds of problem that require these dubious workarounds.

Well, coming from a “strong static types or bust” background, when I first 
worked with Ruby I was shocked at how the world did not fall apart even though 
everything is open to monkey patching! It’s definitely a different mindset — 
but one in which people exercise careful thought, and write good, reliable 
software. This stunned me when I first encountered that world, but it’s an 
empirical fact that it can work quite well. The ways in which it succeeds 
forced me to rethink a lot of how I approach code.

That said, the “everything dynamic and rewirable” way is _clearly_ not the 
Swift way, and with “The same argument implies…,” you’re misreading my argument.

In principle, I lean in favor of final by default. It’s clearly more consistent 
with Swift’s approach. I’m just pointing out that there will need to be 
something of a culture / ecosystem shift if the platform follows Swift’s lead 
toward more defensive programming and tighter control. The approaches that have 
been working for Objective-C library authors, including but not limited to 
Apple, will not continue to work as is.

>> I’m not totally opposed to final by default. Joe’s arguments sway me in 
>> principle. In practice, if Swift does indeed moves us toward “less wiggle 
>> room, less hackable” by default, then that wiggle room _will_ have to come 
>> from somewhere else: perhaps more open sourcing and more forking, or faster 
>> turnaround on fixes from library authors, or a larger portion of time spent 
>> by library authors explicitly exposing and documenting customization points. 
>> The new effort involved for library authors is nothing to sneeze at.
> 
> No, it’s nothing to sneeze at; it is essential for creating reliable 
> software.  As a library author, I support anything that helps produce that 
> level of care :-)

Yes: a high level of care, and also open communication, and faster turnaround, 
and good listening, and … well, exactly the sort of effort Apple is putting 
forth right now for Swift!

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

> I can see why you view it this way, but access control and inheritability are 
> orthogonal.
as I understand orthogonal (mathematical background), it is definitely not the 
case:
I can't inherit what I cannot access, so there is one impossible combination of 
the two attributes.

The argumentation that "users of your framework could cause trouble (what they 
will do anyways ;-) with overriding" looses traction when you have to add "of 
cause that only applies to classes you made explicitly accessible to them".

Final is right in theory, but in real software, classes are rarely designed for 
inheritance — it just happens (and I'm quite sure most real software is build 
by people who would shrug of such discussions as academic nonsense ;-).

Btw: I wouldn't oppose a proposal to allow changing conventions like this 
(there are at least two other discussions about the best default) on a per 
module/file basis — as long as the "local" effect of the setting isn't vital, 
there shouldn't be a problem with customizing.

Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

> NS_REQUIRES_SUPER as the default is a bad idea. There's a big difference 
> between methods where you SHOULD call super and methods where you MUST call 
> super, and NS_REQUIRES_SUPER is meant for the latter case. The problem with 
> using it where you simply SHOULD call super is there's occasionally a good 
> reason to explicitly not call super, but there's no way to suppress the 
> warning in that case (and no obvious syntax to propose for that).
Well, I'm no fan of spoon-feeding developers to protect them from themselves:
I would only insist on the call to super being there, not on it's actual 
execution.

> In addition, the cases where you MUST call super are really extremely rare.
Then one part of the original question has a clear answer: If it's ok to 
override and not call super, final is a bad default — if the original 
implementation is not important, final has only a little benefit in terms of 
performance for the price of restricting the user in a massive way.

Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Dec 22, 2015, at 3:43 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> I can see why you view it this way, but access control and inheritability 
>> are orthogonal.
> as I understand orthogonal (mathematical background), it is definitely not 
> the case:
> I can't inherit what I cannot access, so there is one impossible combination 
> of the two attributes.

Ok, you got me there.  Orthogonal was not the best choice of words.  
Nevertheless, they are independent concerns that happen to interact in this one 
case.

> 
> The argumentation that "users of your framework could cause trouble (what 
> they will do anyways ;-) with overriding" looses traction when you have to 
> add "of cause that only applies to classes you made explicitly accessible to 
> them".
> 
> Final is right in theory, but in real software, classes are rarely designed 
> for inheritance — it just happens (and I'm quite sure most real software is 
> build by people who would shrug of such discussions as academic nonsense ;-).

If the time comes it is certainly a good thing if the language can remind you 
of the fact that you didn't consider it in the initial implementation by 
requiring you to mark the superclass inheritable.

> 
> Btw: I wouldn't oppose a proposal to allow changing conventions like this 
> (there are at least two other discussions about the best default) on a per 
> module/file basis — as long as the "local" effect of the setting isn't vital, 
> there shouldn't be a problem with customizing.

I would really be opposed to this.  It would not be clear when reading code 
what it actually means.  Copy and paste would also be problematic for similar 
reasons.  Flags should not change the semantics of a piece of code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[James Campbell via swift-evolution]

I like the point someone made about unit testing. If subclassing was
disabled then I think there should then be some way of mocking built into
the testing frameworks of swift (Think RSpec but for switt)

On Tue, Dec 22, 2015 at 12:51 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> On Dec 22, 2015, at 3:43 AM, Tino Heth <2...@gmx.de> wrote:
>
>
> I can see why you view it this way, but access control and inheritability
> are orthogonal.
>
> as I understand orthogonal (mathematical background), it is definitely not
> the case:
> I can't inherit what I cannot access, so there is one impossible
> combination of the two attributes.
>
>
> Ok, you got me there.  Orthogonal was not the best choice of words.
> Nevertheless, they are independent concerns that happen to interact in this
> one case.
>
>
> The argumentation that "users of your framework could cause trouble (what
> they will do anyways ;-) with overriding" looses traction when you have to
> add "of cause that only applies to classes you made explicitly accessible
> to them".
>
> Final is right in theory, but in real software, classes are rarely
> designed for inheritance — it just happens (and I'm quite sure most real
> software is build by people who would shrug of such discussions as academic
> nonsense ;-).
>
>
> If the time comes it is certainly a good thing if the language can remind
> you of the fact that you didn't consider it in the initial implementation
> by requiring you to mark the superclass inheritable.
>
>
> Btw: I wouldn't oppose a proposal to allow changing conventions like this
> (there are at least two other discussions about the best default) on a per
> module/file basis — as long as the "local" effect of the setting isn't
> vital, there shouldn't be a problem with customizing.
>
>
> I would really be opposed to this.  It would not be clear when reading
> code what it actually means.  Copy and paste would also be problematic for
> similar reasons.  Flags should not change the semantics of a piece of code.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
ja...@supmenow.com
+44 7523 279 698
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

>> Btw: I wouldn't oppose a proposal to allow changing conventions like this 
>> (there are at least two other discussions about the best default) on a per 
>> module/file basis — as long as the "local" effect of the setting isn't 
>> vital, there shouldn't be a problem with customizing.
> I would really be opposed to this.  It would not be clear when reading code 
> what it actually means.  Copy and paste would also be problematic for similar 
> reasons.  Flags should not change the semantics of a piece of code.
That's what I meant with "local effect":
For an algorithm, it doesn't matter wether it's implemented in a final or 
non-final method, or if it produces warnings that don't happen with different 
compiler flags; and even if you copy whole files from other people with a 
different opinion on sane defaults, the worst thing to happen in the case of 
final is an error when you try to override something that is not explicitly 
marked as non-final.
Imho that's nothing compared to the hoops we had to jump through when ARC was 
introduced — and the alternatives are either arguing forever or deciding to 
annoy a part of the community.
Additionally, as soon as you change the default behavior, the same problems 
arise…

Best regards,
Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Joe Groff via swift-evolution]

> On Dec 21, 2015, at 10:04 AM, Dave Abrahams via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 20, 2015, at 3:51 PM, Michael Buckley via swift-evolution 
>> > wrote:
>> 
>> +0. This seems reasonable, and a lot of the arguments are compelling. The 
>> argument put forth about library design especially so. But coming from C++, 
>> where I have to prefix nearly every method in my classes with virtual, I'm 
>> worried that we could end up  with the same problem in Swift.
>> 
>> We don't know what the dominant paradigm in swift will be ten years from 
>> now. Inheritance has a raft of problems, but there's no guarantee that the 
>> alternatives will be better in the long run. I suspect they will be, but I 
>> also suspect we will find new and exciting problems in large codebases using 
>> more functional patterns.
>> 
>> While there's a lot of excitement in the Swift community right now about 
>> final, value types, and other language features, but I fear that when the 
>> rest of the world jumps on the Swift bandwagon, most are just going to use 
>> classes exclusively over structs and continue their OOP practices, simply 
>> because it's what they're used to.
>> 
>> Making final the default may be a great way to discourage them. But it may 
>> also get us right back to where we are in C++ today, where programmers want 
>> virtual functions 99% of the time, but have to specify each function as 
>> virtual.
> 
> In my considerable experience with C++, that is not at all where we are 
> today.  Increasingly, C++ is becoming seen as a language for high-performance 
> computing, and people working in that area learn that they don't want to pay 
> for virtual dispatch when they don't have to.  It is true that for some of 
> them, reflexive use of OOP is hard to shake, but they do learn eventually.  
> Note also that Swift is really the second major language to take value 
> semantics seriously.  The first was C++.

In C++, you also often see polymorphic type erasure containers built on top of 
types that themselves don't require dynamic dispatch, like `boost::any`, 
`std::function`, and the like. This is something Swift makes first-class with 
protocols and protocol types. You don't need virtual dispatch of 
implementations as much if you can introduce ad-hoc virtual dispatch of 
interfaces at any point.

-Joe___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Dave Abrahams via swift-evolution]

> On Dec 20, 2015, at 3:51 PM, Michael Buckley via swift-evolution 
>  wrote:
> 
> +0. This seems reasonable, and a lot of the arguments are compelling. The 
> argument put forth about library design especially so. But coming from C++, 
> where I have to prefix nearly every method in my classes with virtual, I'm 
> worried that we could end up  with the same problem in Swift.
> 
> We don't know what the dominant paradigm in swift will be ten years from now. 
> Inheritance has a raft of problems, but there's no guarantee that the 
> alternatives will be better in the long run. I suspect they will be, but I 
> also suspect we will find new and exciting problems in large codebases using 
> more functional patterns.
> 
> While there's a lot of excitement in the Swift community right now about 
> final, value types, and other language features, but I fear that when the 
> rest of the world jumps on the Swift bandwagon, most are just going to use 
> classes exclusively over structs and continue their OOP practices, simply 
> because it's what they're used to.
> 
> Making final the default may be a great way to discourage them. But it may 
> also get us right back to where we are in C++ today, where programmers want 
> virtual functions 99% of the time, but have to specify each function as 
> virtual.

In my considerable experience with C++, that is not at all where we are today.  
Increasingly, C++ is becoming seen as a language for high-performance 
computing, and people working in that area learn that they don't want to pay 
for virtual dispatch when they don't have to.  It is true that for some of 
them, reflexive use of OOP is hard to shake, but they do learn eventually.  
Note also that Swift is really the second major language to take value 
semantics seriously.  The first was C++.

> 
> On Sun, Dec 20, 2015 at 2:53 PM, Charles Srstka via swift-evolution 
> > wrote:
> I agree with this. -1 to the proposal.
> 
> Charles
> 
>> On Dec 17, 2015, at 8:00 PM, Rod Brown via swift-evolution 
>> > wrote:
>> 
>> To play devils advocate, take for example UINavigationController in UIKit on 
>> iOS.
>> 
>> I’ve seen multiple times in multiple projects legitimate reasons for 
>> subclassing it, despite the fact that UIKit documentation says we “should 
>> not need to subclass it”. So if we relied on Apple to “declare”, they most 
>> probably wouldn’t, and these use cases (and some really impressive apps) 
>> would become impossible.
>> 
>> While I agree with all points made about “If it’s not declared subclassable, 
>> they didn’t design it that way”, I think that ties everyone’s hands too 
>> much. There is a balance between safety and functionality that must be 
>> worked out. I think this errs way too far on the side of safety.
>> 
>> Rod
>> 
>> 
>>> On 18 Dec 2015, at 12:51 PM, Javier Soto >> > wrote:
>>> 
>>> What if one framework provider thinks “you won’t need to subclass this ever”
>>> 
>>> If the framework author didn't design and implement that class with 
>>> subclassing in mind, chances are it's not necessarily safe to do so, or at 
>>> least not without knowledge of the implementation. That's why I think 
>>> deciding that a class can be subclassed is a decision that should be made 
>>> consciously, and not just "I forgot to make it final"
>>> On Thu, Dec 17, 2015 at 5:41 PM Rod Brown >> > wrote:
>>> My opinion is -1 on this proposal. Classes seem by design to intrinsically 
>>> support subclassing.
>>> 
>>> What if one framework provider thinks “you won’t need to subclass this 
>>> ever” but didn’t realise your use case for doing so, and didn’t add the 
>>> keyword? When multiple developers come at things from different angles, the 
>>> invariable situation ends with use cases each didn’t realise. Allowing 
>>> subclassing by default seems to mitigate this risk at least for the most 
>>> part.
>>> 
>>> I think this definitely comes under the banner of “this would be nice” 
>>> without realising the fact you’d be shooting yourself in the foot when 
>>> someone doesn’t add the keyword in other frameworks and you’re annoyed you 
>>> can’t add it.
>>> 
>>> 
>>> 
 On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution 
 > wrote:
 
>>> 
 Does it seem like there's enough interesest in this proposal? If so, what 
 would be the next steps? Should I go ahead and create a PR on the 
 evolution repo, describing the proposal version that Joe suggested, with 
 classes closed for inheritance by default outside of a module?
 
 Thanks!
 
 On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution 
 

Re: [swift-evolution] Final by default for classes and methods

[Kevin Ballard via swift-evolution]

I was on the fence initially, but you've sold me here. +1 for sealed-by-
default.

-Kevin Ballard

On Sat, Dec 19, 2015, at 07:21 PM, Jordan Rose via swift-evolution wrote:
>
>> On Dec 7, 2015, at 20:30 , John McCall via swift-evolution > evolut...@swift.org> wrote:
>>
>>> On Dec 7, 2015, at 7:18 PM, Matthew Johnson via swift-evolution >> evolut...@swift.org> wrote:
 Defaults of public sealed/final classes and final methods on a
 class by default are a tougher call. Either way you may have design
 issues go unnoticed until someone needs to subclass to get the
 behavior they want. So when you reach that point, should the system
 error on the side of rigid safety or dangerous flexibility?
>>>
>>> This is a nice summary of the tradeoff.  I strongly prefer safety
>>> myself and I believe the preference for safety fits well with the
>>> overall direction of Swift.  If a library author discovers a design
>>> oversight and later decides they should have allowed for additional
>>> flexibility it is straightforward to allow for this without breaking
>>> existing client code.
>>>
>>> Many of the examples cited in argument against final by default have
>>> to do with working around library or framework bugs.  I understand
>>> the motivation to preserve this flexibility bur don't believe bug
>>> workarounds are a good way to make language design decisions. I also
>>> believe use of subclasses and overrides in ways the library author
>>> may not have intended to is a fragile technique that is likely to
>>> eventually cause as many problems as it solves.  I have been
>>> programming a long time and have never run into a case where this
>>> technique was the only way or even the best way to accomplish the
>>> task at hand.
>>>
>>> One additional motivation for making final the default that has not
>>> been discussed yet is the drive towards making Swift a protocol
>>> oriented language.  IMO protocols should be the first tool
>>> considered when dynamic polymorphism is necessary.  Inheritance
>>> should be reserved for cases where other approaches won't work (and
>>> we should seek to reduce the number of problems where that is the
>>> case).  Making final the default for classes and methods would
>>> provide a subtle (or maybe not so subtle) hint in this direction.
>>>
>>> I know the Swift team at Apple put a lot of thought into the
>>> defaults in Swift.  I agree with most of them. Enabling subclassing
>>> and overriding by default is the one case where I think a
>>> significant mistake was made.
>>
>> Our current intent is that public subclassing and overriding will
>> be locked down by default, but internal subclassing and overriding
>> will not be.  I believe that this strikes the right balance, and
>> moreover that it is consistent with the general language approach
>> to code evolution, which is to promote “consequence-free” rapid
>> development by:
>>
>> (1) avoiding artificial bookkeeping obstacles while you’re hacking up
>> the initial implementation of a module, but
>>
>> (2) not letting that initial implementation make implicit source and
>> binary compatibility promises to code outside of the module and
>>
>> (3) providing good language tools for incrementally building those
>> initial prototype interfaces into stronger internal abstractions.
>>
>> All the hard limitations in the defaults are tied to the module
>> boundary because we assume that it’s straightforward to fix any
>> problems within the module if/when you decided you made a mistake
>> earlier.
>>
>> So, okay, a class is subclassable by default, and it wasn’t really
>> designed for that, and now there are subclasses in the module which
>> are causing problems.  As long as nobody's changed the default (which
>> they could have done carelessly in either case, but are much less
>> likely to do if it’s only necessary to make an external subclass),
>> all of those subclasses will still be within the module, and you
>> still have free rein to correct that initial design mistake.
>
> I think John summarized my position very well, so of course I'm going
> to come in here and add more stuff. :-)
>
> In working on the design for library evolution support ("resilience"),
> we've come across a number of cases of "should a library author be
> able to change this when they release v2 of their library?" Many
> times, the answer is it's *possible* to do something in one direction,
> but not at all safe to go the other way. For example, you can always
> add public methods to a class, but you can't *remove* public methods
> because you don't know who's calling them. You can mark them
> deprecated, but that doesn't help with any client apps that have
> already been compiled and shipped.
>
> One of the things that came up was "can you add 'final' to a class?"
> And of course you can't, because you don't know who may have already
> subclassed it. That's very unfortunate for a library author who simply
> forgot to add 'final' when they were first 

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 21, 2015, at 1:26 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Dec 20, 2015, at 3:40 , Tino Heth via swift-evolution 
>> > wrote:
>> 
>> 
>>> Frankly, I think having `final` in the language at all is a mistake. While 
>>> I agree that we should prefer composition to inheritance*, declaring things 
>>> final is hubris. The only reasonable use case I've seen is for 
>>> optimization, but that smacks of developers serving the compiler rather 
>>> than the converse. Bringing an analog of NS_REQUIRES_SUPER to Swift would 
>>> be most welcome; that's as far as I'd go down the path of dictating 
>>> framework usage.
>> I really like the direction this discussion has taken ;-):
>> Is there any counter argument beside performance (which imho should always 
>> be seen under the aspect of premature optimization) that speaks against 
>> making NS_REQUIRES_SUPER the default behavior?
> 
> I personally don't like this but I can't put my finger on why. Obviously 
> there are some things where you really don't need to call super (mostly 
> abstract methods), but you just said "default", which implies that we could 
> have an opt-out attribute.
> 
> I will say, however, that making NS_REQUIRES_SUPER the default for 
> overridable methods is separable from deciding which methods are overridable 
> by default. Making sure the base method is called isn't really the same as 
> knowing the base method is all that's called.

Agree.  There are at least four possibilities from most to least restrictive:

* not overridable
* overridable but requires a call to super in a specific location in the 
overriding method (i.e. the first or last line)
* overridable but requires a call to super somewhere in the overriding method
* overridable with no restrictions


> 
> Jordan
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

> Obviously there are some things where you really don't need to call super 
> (mostly abstract methods), but you just said "default", which implies that we 
> could have an opt-out attribute.
> 
> I will say, however, that making NS_REQUIRES_SUPER the default for 
> overridable methods is separable from deciding which methods are overridable 
> by default. Making sure the base method is called isn't really the same as 
> knowing the base method is all that's called.
Well, there are the two extreme positions:
final is as restrictive as possible and the current default, which allows to 
completely eliminate the inherited code.
NS_REQUIRES_SUPER (the name is imho the by far worst thing of this feature… 
inheritable sounds really better) is a compromise:
You can make sure that a method does what you want it to do without patronizing 
the user — and of course theres still room (and need) for final and nonfinal.

Tino___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Jordan Rose via swift-evolution]

> On Dec 20, 2015, at 3:40 , Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> Frankly, I think having `final` in the language at all is a mistake. While I 
>> agree that we should prefer composition to inheritance*, declaring things 
>> final is hubris. The only reasonable use case I've seen is for optimization, 
>> but that smacks of developers serving the compiler rather than the converse. 
>> Bringing an analog of NS_REQUIRES_SUPER to Swift would be most welcome; 
>> that's as far as I'd go down the path of dictating framework usage.
> I really like the direction this discussion has taken ;-):
> Is there any counter argument beside performance (which imho should always be 
> seen under the aspect of premature optimization) that speaks against making 
> NS_REQUIRES_SUPER the default behavior?

I personally don't like this but I can't put my finger on why. Obviously there 
are some things where you really don't need to call super (mostly abstract 
methods), but you just said "default", which implies that we could have an 
opt-out attribute.

I will say, however, that making NS_REQUIRES_SUPER the default for overridable 
methods is separable from deciding which methods are overridable by default. 
Making sure the base method is called isn't really the same as knowing the base 
method is all that's called.

Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

> - 'private' and 'internal' methods are not exposed outside of a library, so 
> you can't call them, much less override them. Similar for 'private' and 
> 'internal' classes: you cannot subclass them.
really important point — and imho one of the best arguments not to make final 
the default:
It IS already the default (practically), so all points regarding own frameworks 
used by other parties become much less relevant.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Kevin Ballard via swift-evolution]

Overriding is not normally how you test classes to begin with.

The traditional Obj-C way of testing classes like that is to use a
mocking library, that provides NSProxy objects that forward non-stubbed
methods to the original class (or forward everything and merely record
which methods were invoked). This of course only works for classes that
use the Obj-C runtime.

The approach that is often recommended for Swift is to use protocol-
oriented programming, where you expose things as protocols instead of as
classes. That way you can provide your own implementation of the
protocol in order to mock something out.

-Kevin Ballard

On Mon, Dec 21, 2015, at 09:35 AM, Tomáš Linhart via swift-evolution wrote:
> But tell me how will you test your code that is depending on a class
> provided by external party? You cannot subclass so you cannot override
> the behaviour that you need stub, at the you will wrap entire library
> in your own classes that you can subclass but what for? Subclassing
> rarely breaks things and if it does, you should mark it final but it
> shouldn't be explicit.
>
> Tomáš
>
> On Mon, Dec 21, 2015 at 6:31 PM, Javier Soto
>  wrote:
>> I think it's just as important for methods. If you make a class
>> final, all methods become final, so that's OK. But if you make a
>> class subclassable, and then forget to mark some of it's methods
>> final, then all methods would be overridable which is probably not
>> what you'd want in must cases. On Mon, Dec 21, 2015 at 9:19 AM Tomáš
>> Linhart  wrote:
>>> Hello,
>>>
>>> I must say, I am not big fun of this proposal because currently in
>>> Swift only way how to mock classes is to subclass them. If this
>>> proposal becomes reality, it will make mocking of all third-party
>>> libraries impossible unless they mark their classes non-final and I
>>> am afraid authors will just use the default behaviour so at the end
>>> people will stop testing code that is using third-party libraries or
>>> they will have to fork the libraries or ask the authors. This can be
>>> fixed by having better testing support in Swift but I don't think,
>>> this will happen anytime soon.
>>>
>>> I would rather see introduction of better reflection so mock
>>> frameworks can be reality. I would like to see also other building
>>> block of objected-oriented-programming such as abstract classes,
>>> protocols with generic type parameters and not just abstract types
>>> (associated types) that allows to design better APIs that don't
>>> depend so much on overriding regular classes.
>>>
>>>
>>> Tomáš
>>>
>>
>> --
>> Javier Soto
>>
>
> _
> swift-evolution mailing list swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[David Waite via swift-evolution]

A proposal could allow subclassing final/sealed classes when using @testable 
import

-DW
Sent with my Thumbs

> On Dec 21, 2015, at 10:18 AM, Tomáš Linhart via swift-evolution 
>  wrote:
> 
> Hello,
> 
> I must say, I am not big fun of this proposal because currently in Swift only 
> way how to mock classes is to subclass them. If this proposal becomes 
> reality, it will make mocking of all third-party libraries impossible unless 
> they mark their classes non-final and I am afraid authors will just use the 
> default behaviour so at the end people will stop testing code that is using 
> third-party libraries or they will have to fork the libraries or ask the 
> authors. This can be fixed by having better testing support in Swift but I 
> don't think, this will happen anytime soon.
> 
> I would rather see introduction of better reflection so mock frameworks can 
> be reality. I would like to see also other building block of 
> objected-oriented-programming such as abstract classes, protocols with 
> generic type parameters and not just abstract types (associated types) that 
> allows to design better APIs that don't depend so much on overriding regular 
> classes.
> 
> Tomáš
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Rod Brown via swift-evolution]

I must agree entirely with Brent’s assessment here.

Can swift be a language that can go down as low-level as high performance 
computing? Absolutely. But need we tie our hands with the limitations as such? 
I don’t think so. Safety must give way to sensibility when the costs are this 
high.


> On 22 Dec 2015, at 5:31 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> In my considerable experience with C++, that is not at all where we are 
>> today.  Increasingly, C++ is becoming seen as a language for 
>> high-performance computing, and people working in that area learn that they 
>> don't want to pay for virtual dispatch when they don't have to.  It is true 
>> that for some of them, reflexive use of OOP is hard to shake, but they do 
>> learn eventually.
> 
> Is Swift's goal to be a perfect language for high-performance computing? I 
> thought it was to be a language that scales from scripting to systems 
> programming, with a nice sweet spot around application development.
> 
> For application development, speed is certainly good, but it is not the 
> priority. We want Swift to go fast wherever we can get those speed gains 
> without much cost, of course, but I worry that the cost of this proposal is 
> too high. Just imagine going through UIKit and marking every class 
> inheritable *by hand*—no cheating with a script—and you'll have some idea of 
> the additional burden you'll be imposing on developers as they write their 
> code. The proposals that every single method should be explicitly marked as 
> overridable are even worse; frankly, I don't think I'd want to use Swift if 
> you forced me to put a `virtual` keyword on every declaration.
> 
> I worry that the team's use of Swift to build the standard library, and their 
> close association with teams building OS frameworks, is biasing the language 
> a little bit. I think that, in all likelihood, most Swift code is in 
> individual applications, and most libraries are not published outside of a 
> single team. If I'm right, then most Swift code will probably be quite 
> tolerant of small but technically "breaking" ABI changes, such as making a 
> class `final`, or (as mentioned in another thread) making a closure 
> `@noescape`.
> 
> That won't be true of published library code, of course. But published 
> library code is a small minority of the Swift code people will write, and it 
> already will require greater scrutiny and more careful design. 
> 
> There is already a good opportunity to reflect on whether or not an API 
> should be `final`. It's when you put the `public` keyword on it. I think 
> programmers will have a better, easier time writing their code if, in this 
> case, we put a little bit of trust in them, rather than erecting yet another 
> hoop they must jump through.
> 
> Perhaps we could even provide a "strict interfaces" mode that published 
> frameworks can turn on, which would require you to declare the heritability 
> of every class and member. But even that may not be a good idea, because I 
> also suspect that, in the field, most published libraries probably have to be 
> extended in ways the library's author did not expect or anticipate. 
> 
> This means doing some dangerous overriding, yes. But a UI that breaks after 
> an iOS upgrade is not nearly as dangerous to my business as a three-month 
> delay while I reimplement half of UIKit because someone in Cupertino thought 
> they knew what I need better than I do and turned off—or even worse, *left 
> turned off without a single thought*—subclassing of UIBarButtonItem.
> 
> The bottom line is this: Your users like Swift's strictures when they're 
> helpful. *This stricture is not helpful.* Library users don't accidentally 
> subclass things, and with the `override` keyword in Swift, they don't 
> accidentally override them either. And where it truly is important, for 
> safety or for speed, to prevent subclassing, we already have `final`. Making 
> it the default is less safety than suffering.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Dave Abrahams via swift-evolution]

> On Dec 21, 2015, at 10:31 PM, Brent Royal-Gordon  
> wrote:
> 
>> In my considerable experience with C++, that is not at all where we are 
>> today.  Increasingly, C++ is becoming seen as a language for 
>> high-performance computing, and people working in that area learn that they 
>> don't want to pay for virtual dispatch when they don't have to.  It is true 
>> that for some of them, reflexive use of OOP is hard to shake, but they do 
>> learn eventually.
> 
> Is Swift's goal to be a perfect language for high-performance computing? 

I don't think I said or suggested anything like that.

-Dave



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Brent Royal-Gordon via swift-evolution]

> In my considerable experience with C++, that is not at all where we are 
> today.  Increasingly, C++ is becoming seen as a language for high-performance 
> computing, and people working in that area learn that they don't want to pay 
> for virtual dispatch when they don't have to.  It is true that for some of 
> them, reflexive use of OOP is hard to shake, but they do learn eventually.

Is Swift's goal to be a perfect language for high-performance computing? I 
thought it was to be a language that scales from scripting to systems 
programming, with a nice sweet spot around application development.

For application development, speed is certainly good, but it is not the 
priority. We want Swift to go fast wherever we can get those speed gains 
without much cost, of course, but I worry that the cost of this proposal is too 
high. Just imagine going through UIKit and marking every class inheritable *by 
hand*—no cheating with a script—and you'll have some idea of the additional 
burden you'll be imposing on developers as they write their code. The proposals 
that every single method should be explicitly marked as overridable are even 
worse; frankly, I don't think I'd want to use Swift if you forced me to put a 
`virtual` keyword on every declaration.

I worry that the team's use of Swift to build the standard library, and their 
close association with teams building OS frameworks, is biasing the language a 
little bit. I think that, in all likelihood, most Swift code is in individual 
applications, and most libraries are not published outside of a single team. If 
I'm right, then most Swift code will probably be quite tolerant of small but 
technically "breaking" ABI changes, such as making a class `final`, or (as 
mentioned in another thread) making a closure `@noescape`.

That won't be true of published library code, of course. But published library 
code is a small minority of the Swift code people will write, and it already 
will require greater scrutiny and more careful design. 

There is already a good opportunity to reflect on whether or not an API should 
be `final`. It's when you put the `public` keyword on it. I think programmers 
will have a better, easier time writing their code if, in this case, we put a 
little bit of trust in them, rather than erecting yet another hoop they must 
jump through.

Perhaps we could even provide a "strict interfaces" mode that published 
frameworks can turn on, which would require you to declare the heritability of 
every class and member. But even that may not be a good idea, because I also 
suspect that, in the field, most published libraries probably have to be 
extended in ways the library's author did not expect or anticipate. 

This means doing some dangerous overriding, yes. But a UI that breaks after an 
iOS upgrade is not nearly as dangerous to my business as a three-month delay 
while I reimplement half of UIKit because someone in Cupertino thought they 
knew what I need better than I do and turned off—or even worse, *left turned 
off without a single thought*—subclassing of UIBarButtonItem.

The bottom line is this: Your users like Swift's strictures when they're 
helpful. *This stricture is not helpful.* Library users don't accidentally 
subclass things, and with the `override` keyword in Swift, they don't 
accidentally override them either. And where it truly is important, for safety 
or for speed, to prevent subclassing, we already have `final`. Making it the 
default is less safety than suffering.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Matthew Johnson via swift-evolution]

> On Dec 21, 2015, at 10:11 AM, Tino Heth <2...@gmx.de> wrote:
> 
>> This is obviously not a scientific sample and is not too large, but it is 
>> probably enough to give some sense of how inheritance is used by app 
>> developers as well as their opinions about final as default.
> “I only believe in statistics that I doctored myself” - this quote is still 
> true, and more than 95% of all statistic results are wrong ;-)
> No, seriously, there are several arguments to not overestimate the value of 
> the poll:
> - There is bias in the form that you are more likely to view the poll submit 
> a vote if you want final to be the default
> - I bet no one really calculated the percentage numbers, but rather choose a 
> value that fits better to his preferred result
> - The poll starts with questions that filter out opponents that don't want to 
> lie about their numbers (I could easily say I subclass everything just to 
> change the numbers in favor of non-final… but that's not only unfair, but 
> also easy to prove untrue :)
> 
>> "What percent of the classes you write are subclasses of classes other than 
>> Apple provided framework or open source library classes?”
>> 
>> 66.67% indicate such subclasses only comprise 0-20% of the classes they 
>> write.
>> 14.49% indicate such subclasses comprise 20-40% of the classes they write.
> That's mostly building complicated numbers...
> 
>> 72.73% believe that final should be the default behavior.
> No, this is a simple number without much room for interpretation: Nearly 3/4 
> of all who took part on the poll (that is an important aspect) want final to 
> be the default. But wait...
> 
>> 48.48% prefer an `inheritable` keyword when inheritance is intended.  An 
>> additional 15.15% prefer a `nonfinal` keyword for this behavior.  64.15% 
>> prefer one of the two.  Only 36.36% prefer the current state of using 
>> `final`.
> Hu? Three choices, and two are just different names for the same? And the 
> numbers don't add up to the same values??
> I can't see where "inheritable" is explained; naturally, I would take it as 
> "you can extend what's already there, but not overwrite it"
> 
>> Obviously there are slight differences between questions that are 
>> effectively asking the same thing.  My guess is that this can be attributed 
>> to misunderstanding of the question in some cases.  
> ah, ok - at least it's addressed
> 
>> The data points to a strong trend.  Most classes written by respondents at 
>> the app level are not intended to be subclassed.  Aligning with this trend 
>> in frequency, most of the respondents would prefer final to be the default 
>> behavior.
> Which might be already the case — we are encouraged to use structs, and those 
> can only be final.
> One major differentiation for classes is that they can be subclassed, and if 
> that is not wanted, maybe a struct would be better anyways…
> 
> Nonetheless, I still would switch to the "final by default" camp if you have 
> a convincing answer to a simple question:
> Why shouldn't inheritable (with the consequences outlined above) be the 
> default? (if you read and answer at all, I'm fine when you discard the whole 
> message if one this point is addressed…)

Hi Tino,

Thanks for taking time to respond.  I make no claims as to sound conclusions 
that can be drawn from the poll.  It is absolutely anecdotal.  I called out the 
unscientific nature of the poll right from the start.  You could be right about 
bias towards those who want final to be the default, but there are equally 
passionate people on the other side of this debate who may be motivated to 
respond as well.  It’s impossible to tell.

My conclusion states: "at a minimum I hope it encourages us to look deeper at 
this issue and gather additional data to find out whether the pattern 
identified by the survey holds more broadly.”  I don’t go any further than 
that.  But I do think it is wise to do this.  A lot of people are moving away 
from heavy reliance on inheritance in their Swift code.  Anecdotal data 
confirming this seems to be enough to warrant a closer look IMO.

You are correct that we can use value types in many cases and value types do 
not allow inheritance.  However, any Swift application is necessarily going to 
have a lot of classes as the Cocoa frameworks require apps to subclass 
framework classes in many instances.  Even when we are not required to subclass 
a framework class they often require our types to be a class, for example when 
we are providing a delegate to a Cocoa class.  These requirements of the 
frameworks result in a lot of classes in Swift applications that are not ever 
intended to be subclassed.

You ask why I don’t think `inheritable` should be the default.  I believe I 
have addressed that by making a case that it is less clear and less safe as a 
default.  Swift prioritizes safety and clarity so I believe the defaults should 
be influenced by those priorities.  If you have specific criticisms of the 

Re: [swift-evolution] Final by default for classes and methods

[Charles Srstka via swift-evolution]

I agree with this. -1 to the proposal.

Charles

> On Dec 17, 2015, at 8:00 PM, Rod Brown via swift-evolution 
>  wrote:
> 
> To play devils advocate, take for example UINavigationController in UIKit on 
> iOS.
> 
> I’ve seen multiple times in multiple projects legitimate reasons for 
> subclassing it, despite the fact that UIKit documentation says we “should not 
> need to subclass it”. So if we relied on Apple to “declare”, they most 
> probably wouldn’t, and these use cases (and some really impressive apps) 
> would become impossible.
> 
> While I agree with all points made about “If it’s not declared subclassable, 
> they didn’t design it that way”, I think that ties everyone’s hands too much. 
> There is a balance between safety and functionality that must be worked out. 
> I think this errs way too far on the side of safety.
> 
> Rod
> 
> 
>> On 18 Dec 2015, at 12:51 PM, Javier Soto > > wrote:
>> 
>> What if one framework provider thinks “you won’t need to subclass this ever”
>> 
>> If the framework author didn't design and implement that class with 
>> subclassing in mind, chances are it's not necessarily safe to do so, or at 
>> least not without knowledge of the implementation. That's why I think 
>> deciding that a class can be subclassed is a decision that should be made 
>> consciously, and not just "I forgot to make it final"
>> On Thu, Dec 17, 2015 at 5:41 PM Rod Brown > > wrote:
>> My opinion is -1 on this proposal. Classes seem by design to intrinsically 
>> support subclassing.
>> 
>> What if one framework provider thinks “you won’t need to subclass this ever” 
>> but didn’t realise your use case for doing so, and didn’t add the keyword? 
>> When multiple developers come at things from different angles, the 
>> invariable situation ends with use cases each didn’t realise. Allowing 
>> subclassing by default seems to mitigate this risk at least for the most 
>> part.
>> 
>> I think this definitely comes under the banner of “this would be nice” 
>> without realising the fact you’d be shooting yourself in the foot when 
>> someone doesn’t add the keyword in other frameworks and you’re annoyed you 
>> can’t add it.
>> 
>> 
>> 
>>> On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution 
>>> > wrote:
>>> 
>> 
>>> Does it seem like there's enough interesest in this proposal? If so, what 
>>> would be the next steps? Should I go ahead and create a PR on the evolution 
>>> repo, describing the proposal version that Joe suggested, with classes 
>>> closed for inheritance by default outside of a module?
>>> 
>>> Thanks!
>>> 
>>> On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution 
>>> > wrote:
>>> I understand the rationale, I just disagree with it.
>>> 
>>> IMO adding a keyword to state your intention for inheritance is not a 
>>> significant obstacle to prototyping and is not artificial bookkeeping.  I 
>>> really don't understand how this would conflict with "consequence-free" 
>>> rapid development.  It is a good thing to require people to stop and think 
>>> before using inheritance.  Often there is a more appropriate alternative.
>>> 
>>> The assumption that it is straightforward to fix problems within a module 
>>> if you later decide you made a mistake is true in some respects but not in 
>>> others.  It is not uncommon for apps to be monolithic rather than being 
>>> well factored into separate modules, with many developers contributing and 
>>> the team changing over time.  While this is not ideal it is reality.
>>> 
>>> When you have the full source it is certainly *possible* to solve any 
>>> problem but it is often not straightforward at all.  Here is an example of 
>>> a real-work scenario app developers might walk into:
>>> 
>>> 1) A class is developed without subclassing in mind by one developer.
>>> 2) After the original developer is gone another developer adds some 
>>> subclasses without stopping to think about whether the original developer 
>>> designed for subclassing, thereby introducing subtle bugs into the app.
>>> 3) After the second developer is gone the bugs are discovered, but by this 
>>> time there are nontrivial dependencies on the subclasses.
>>> 4) A third developer who probably has little or no context for the 
>>> decisions made by previous developers is tasked with fixing the bugs.
>>> 
>>> This can be quite a knot to untangle, especially if there are problems 
>>> modifying the superclass to properly support the subclasses (maybe this 
>>> breaks the contract the superclass has with its original clients).
>>> 
>>> It may have been possible to avoid the whole mess if the second developer 
>>> was required to add 'inheritable' and 'overrideable' keywords or similar.  
>>> They are 

Re: [swift-evolution] Final by default for classes and methods

[Michael Buckley via swift-evolution]

+0. This seems reasonable, and a lot of the arguments are compelling. The
argument put forth about library design especially so. But coming from C++,
where I have to prefix nearly every method in my classes with virtual, I'm
worried that we could end up  with the same problem in Swift.

We don't know what the dominant paradigm in swift will be ten years from
now. Inheritance has a raft of problems, but there's no guarantee that the
alternatives will be better in the long run. I suspect they will be, but I
also suspect we will find new and exciting problems in large codebases
using more functional patterns.

While there's a lot of excitement in the Swift community right now about
final, value types, and other language features, but I fear that when the
rest of the world jumps on the Swift bandwagon, most are just going to use
classes exclusively over structs and continue their OOP practices, simply
because it's what they're used to.

Making final the default may be a great way to discourage them. But it may
also get us right back to where we are in C++ today, where programmers want
virtual functions 99% of the time, but have to specify each function as
virtual.

On Sun, Dec 20, 2015 at 2:53 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree with this. -1 to the proposal.
>
> Charles
>
> On Dec 17, 2015, at 8:00 PM, Rod Brown via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> To play devils advocate, take for example UINavigationController in UIKit
> on iOS.
>
> I’ve seen multiple times in multiple projects legitimate reasons for
> subclassing it, despite the fact that UIKit documentation says we “should
> not need to subclass it”. So if we relied on Apple to “declare”, they most
> probably wouldn’t, and these use cases (and some really impressive apps)
> would become impossible.
>
> While I agree with all points made about “If it’s not declared
> subclassable, they didn’t design it that way”, I think that ties everyone’s
> hands too much. There is a balance between safety and functionality that
> must be worked out. I think this errs way too far on the side of safety.
>
> Rod
>
>
> On 18 Dec 2015, at 12:51 PM, Javier Soto  wrote:
>
> What if one framework provider thinks “you won’t need to subclass this
> ever”
>
> If the framework author didn't design and implement that class with
> subclassing in mind, chances are it's not necessarily safe to do so, or at
> least not without knowledge of the implementation. That's why I think
> deciding that a class can be subclassed is a decision that should be made
> consciously, and not just "I forgot to make it final"
> On Thu, Dec 17, 2015 at 5:41 PM Rod Brown 
> wrote:
>
>> My opinion is -1 on this proposal. Classes seem by design to
>> intrinsically support subclassing.
>>
>> What if one framework provider thinks “you won’t need to subclass this
>> ever” but didn’t realise your use case for doing so, and didn’t add the
>> keyword? When multiple developers come at things from different angles, the
>> invariable situation ends with use cases each didn’t realise. Allowing
>> subclassing by default seems to mitigate this risk at least for the most
>> part.
>>
>> I think this definitely comes under the banner of “this would be nice”
>> without realising the fact you’d be shooting yourself in the foot when
>> someone doesn’t add the keyword in other frameworks and you’re annoyed you
>> can’t add it.
>>
>>
>> On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Does it seem like there's enough interesest in this proposal? If so, what
>> would be the next steps? Should I go ahead and create a PR on the evolution
>> repo, describing the proposal version that Joe suggested, with classes
>> closed for inheritance by default outside of a module?
>>
>> Thanks!
>>
>> On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I understand the rationale, I just disagree with it.
>>>
>>> IMO adding a keyword to state your intention for inheritance is not a
>>> significant obstacle to prototyping and is not artificial bookkeeping.  I
>>> really don't understand how this would conflict with "consequence-free"
>>> rapid development.  It is a good thing to require people to stop and think
>>> before using inheritance.  Often there is a more appropriate alternative.
>>>
>>> The assumption that it is straightforward to fix problems within a
>>> module if you later decide you made a mistake is true in some respects but
>>> not in others.  It is not uncommon for apps to be monolithic rather than
>>> being well factored into separate modules, with many developers
>>> contributing and the team changing over time.  While this is not ideal it
>>> is reality.
>>>
>>> When you have the full source it is certainly *possible* to solve any
>>> problem but it is often not straightforward at all.  Here 

Re: [swift-evolution] Final by default for classes and methods

[Javier Soto via swift-evolution]

and you get to test betas of future iOS releases anyway, so if something
breaks, you'll catch it and release a fix.

That assumes that all apps get updated when new OS releases come out, and
that's not true. Many apps stop being maintained, but they may have many
users, and Apple does whatever they can to make sure apps don't break when
users update iOS. The reality is that Apple spends a lot of time working
around hacks implemented in apps like swizzling, etc.

I'm really worried about the world where monkey-patching iOS internals is
no longer possible

I'm excited about that world, because Apple won't have to waste time
worrying about ugly hacks, and they can focus on fixing bugs instead.

In any case, this proposal is about final by default. Final is already part
of the language, and I'm sure Apple wouldn't hesitate to use it extensively
when/if they write frameworks in Swift, so I don't think this proposal
would change that.
On Sun, Dec 20, 2015 at 1:17 PM Andrey Tarantsov 
wrote:

> This is another proposal that's right on principle, but breaks down in
> real-world scenarios.
>
> To play devils advocate, take for example UINavigationController in UIKit
> on iOS.
>
>
> This.
>
> Real iOS apps subclass and override things that were never supposed to be
> overridden, swizzle iOS internals and do a lot of other nasty stuff,
> because sometimes that's the only way to get the effect you want, and you
> get to test betas of future iOS releases anyway, so if something breaks,
> you'll catch it and release a fix.
>
> I'm really worried about the world where monkey-patching iOS internals is
> no longer possible. Thankfully, a Swift-based UIKit isn't anywhere on the
> horizon.
>
> ON THE OTHER HAND, I do agree with this proposal for our own code. I've
> always used
>
> // override point
>
>
> to mark methods designed to be overridden, and a keyword to document this
> formally would be appreciated.
>
> A.
>
> --
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Tino Heth via swift-evolution]

> Frankly, I think having `final` in the language at all is a mistake. While I 
> agree that we should prefer composition to inheritance*, declaring things 
> final is hubris. The only reasonable use case I've seen is for optimization, 
> but that smacks of developers serving the compiler rather than the converse. 
> Bringing an analog of NS_REQUIRES_SUPER to Swift would be most welcome; 
> that's as far as I'd go down the path of dictating framework usage.
I really like the direction this discussion has taken ;-):
Is there any counter argument beside performance (which imho should always be 
seen under the aspect of premature optimization) that speaks against making 
NS_REQUIRES_SUPER the default behavior?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Rod Brown via swift-evolution]

These arguments are definitely compelling. I would have to agree with this 
strongly. Very fair reasoning.

> On 20 Dec 2015, at 2:21 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
>> On Dec 7, 2015, at 20:30 , John McCall via swift-evolution 
>> > wrote:
>> Our current intent is that public subclassing and overriding will be locked 
>> down by default, but internal subclassing and overriding will not be.  I 
>> believe that this strikes the right balance, and moreover that it is 
>> consistent with the general language approach to code evolution, which is to 
>> promote “consequence-free” rapid development by:
>> 
>>  (1) avoiding artificial bookkeeping obstacles while you’re hacking up the 
>> initial implementation of a module, but
>> 
>>  (2) not letting that initial implementation make implicit source and binary 
>> compatibility promises to code outside of the module and
>> 
>>  (3) providing good language tools for incrementally building those initial 
>> prototype interfaces into stronger internal abstractions.
>> 
>> All the hard limitations in the defaults are tied to the module boundary 
>> because we assume that it’s straightforward to fix any problems within the 
>> module if/when you decided you made a mistake earlier.
>> 
>> So, okay, a class is subclassable by default, and it wasn’t really designed 
>> for that, and now there are subclasses in the module which are causing 
>> problems.  As long as nobody's changed the default (which they could have 
>> done carelessly in either case, but are much less likely to do if it’s only 
>> necessary to make an external subclass), all of those subclasses will still 
>> be within the module, and you still have free rein to correct that initial 
>> design mistake.
> 
> I think John summarized my position very well, so of course I'm going to come 
> in here and add more stuff. :-)
> 
> In working on the design for library evolution support ("resilience"), we've 
> come across a number of cases of "should a library author be able to change 
> this when they release v2 of their library?" Many times, the answer is it's 
> possible to do something in one direction, but not at all safe to go the 
> other way. For example, you can always add public methods to a class, but you 
> can't remove public methods because you don't know who's calling them. You 
> can mark them deprecated, but that doesn't help with any client apps that 
> have already been compiled and shipped.
> 
> One of the things that came up was "can you add 'final' to a class?" And of 
> course you can't, because you don't know who may have already subclassed it. 
> That's very unfortunate for a library author who simply forgot to add 'final' 
> when they were first writing the class.
> 
> The interesting thing about this is that the "error of omission"—of failing 
> to think about whether a class should be final—is worse than the alternative. 
> Ignoring optimizations for a minute, a class that starts out 'final' can 
> certainly become non-final later; it doesn't change how the class is 
> currently used.* For a lot of library evolution questions, this is the 
> preferred answer: the default should be safe, and the designer of the class 
> can choose to be more aggressive later.
> 
> This is also the guiding principle behind the behavior of 'public'. A number 
> of people have asked for members of a public struct to implicitly be made 
> public. But here again the "error of omission" is problematic: a helper 
> function you add for your own use may now be depended on by client apps far 
> and wide, just because you forgot to customize the access control. So Swift 
> says you should explicitly consider the public interface of every type.
> 
> Why 'sealed' instead of 'final' as the default? Because inheritance is 
> useful, and within your own code having to opt into it starts to feel like 
> unnecessary clutter. This is a trade-off, just like defaulting to 'internal' 
> over 'private', but it's one that keeps life easy for a single developer with 
> a single module: their app. (And the compiler can still do useful things with 
> non-final classes if it can see the entire class hierarchy.) Additionally, 
> limiting inheritance to the current file (a la 'private') is also potentially 
> useful.
> 
> This direction separates "limiting inheritance/overrides" from "has no 
> subclasses/overrides". The former is about defining the limits of your API; 
> the latter is a promise that can be used for performance. I think that's a 
> good thing.
> 
> Jordan
> 
> * Even without optimizations a 'final' class cannot safely drop the 'final'. 
> If a class is 'final', it may have additional 'required' initializers added 
> in extensions.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Final by default for classes and methods

[Dennis Lysenko via swift-evolution]

Actually, Curt, not that I'm in favor of this proposal, but you inspired an
interesting thought--I think that if extensions were more powerful (e.g.
stored properties), then having closed classes by default might not be such
a big deal. What's the difference between using a `MyViewController`
subclass throughout your app to hack around Cocoa's limitations and writing
an extension for UIViewController to use app-wide? The only significant
difference would probably be a couple fewer hackarounds in the
UIViewController case.

Of course, it would break a lot of existing code *without a way to
automatically migrate it*. That's a deal breaker for me.

On Sat, Dec 19, 2015 at 10:09 PM Curt Clifton via swift-evolution <
swift-evolution@swift.org> wrote:

> I'm not sure how many minuses I have to give, but I'd give them all to
> this proposal.
>
> Anyone who tries to ship products on release day of Apple's operating
> system updates spends most of August and September writing horrible hacks
> so that their users are insulated from OS bugs as much as possible. All
> software has bugs, frameworks included. Please don't take away our tools
> for working around those bugs. Making classes final by default assumes a
> level of perfection on the part of framework developers that is not
> achievable.
>
> Yes, subclassing a class that wasn't designed to be subclassed has serious
> risks. Thoughtful developers sometimes take on those risks in order to
> serve their customers.
>
> Frankly, I think having `final` in the language at all is a mistake. While
> I agree that we should prefer composition to inheritance*, declaring things
> final is hubris. The only reasonable use case I've seen is for
> optimization, but that smacks of developers serving the compiler rather
> than the converse. Bringing an analog of NS_REQUIRES_SUPER to Swift would
> be most welcome; that's as far as I'd go down the path of dictating
> framework usage.
>
> Cheers,
>
> Curt
>
> *- and am thrilled with the property behaviors proposal for this use case
>
>
> On Dec 17, 2015, at 5:55 PM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Dec 17, 2015, at 5:41 PM, Rod Brown via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> My opinion is -1 on this proposal. Classes seem by design to intrinsically
> support subclassing.
>
> What if one framework provider thinks “you won’t need to subclass this
> ever” but didn’t realise your use case for doing so, and didn’t add the
> keyword? When multiple developers come at things from different angles, the
> invariable situation ends with use cases each didn’t realise. Allowing
> subclassing by default seems to mitigate this risk at least for the most
> part.
>
>
> Frameworks change, and if the framework author didn't anticipate your use
> case for subclassing, they almost certainly aren't going to anticipate it
> while evolving their implementation and will likely break your code. Robust
> subclassability requires conscious design just like all other aspects of
> API design.
>
> -Joe
>
> I think this definitely comes under the banner of “this would be nice”
> without realising the fact you’d be shooting yourself in the foot when
> someone doesn’t add the keyword in other frameworks and you’re annoyed you
> can’t add it.
>
>
> On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Does it seem like there's enough interesest in this proposal? If so, what
> would be the next steps? Should I go ahead and create a PR on the evolution
> repo, describing the proposal version that Joe suggested, with classes
> closed for inheritance by default outside of a module?
>
> Thanks!
>
> On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I understand the rationale, I just disagree with it.
>>
>> IMO adding a keyword to state your intention for inheritance is not a
>> significant obstacle to prototyping and is not artificial bookkeeping.  I
>> really don't understand how this would conflict with "consequence-free"
>> rapid development.  It is a good thing to require people to stop and think
>> before using inheritance.  Often there is a more appropriate alternative.
>>
>> The assumption that it is straightforward to fix problems within a module
>> if you later decide you made a mistake is true in some respects but not in
>> others.  It is not uncommon for apps to be monolithic rather than being
>> well factored into separate modules, with many developers contributing and
>> the team changing over time.  While this is not ideal it is reality.
>>
>> When you have the full source it is certainly *possible* to solve any
>> problem but it is often not straightforward at all.  Here is an example of
>> a real-work scenario app developers might walk into:
>>
>> 1) A class is developed without subclassing in mind by one developer.
>> 2) After the original developer is gone another developer adds some

Re: [swift-evolution] Final by default for classes and methods

[Jordan Rose via swift-evolution]

> On Dec 7, 2015, at 20:30 , John McCall via swift-evolution 
>  wrote:
> 
>> On Dec 7, 2015, at 7:18 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>>> Defaults of public sealed/final classes and final methods on a class by 
>>> default are a tougher call. Either way you may have design issues go 
>>> unnoticed until someone needs to subclass to get the behavior they want. So 
>>> when you reach that point, should the system error on the side of rigid 
>>> safety or dangerous flexibility?
>> 
>> This is a nice summary of the tradeoff.  I strongly prefer safety myself and 
>> I believe the preference for safety fits well with the overall direction of 
>> Swift.  If a library author discovers a design oversight and later decides 
>> they should have allowed for additional flexibility it is straightforward to 
>> allow for this without breaking existing client code.  
>> 
>> Many of the examples cited in argument against final by default have to do 
>> with working around library or framework bugs.  I understand the motivation 
>> to preserve this flexibility bur don't believe bug workarounds are a good 
>> way to make language design decisions. I also believe use of subclasses and 
>> overrides in ways the library author may not have intended to is a fragile 
>> technique that is likely to eventually cause as many problems as it solves.  
>> I have been programming a long time and have never run into a case where 
>> this technique was the only way or even the best way to accomplish the task 
>> at hand.
>> 
>> One additional motivation for making final the default that has not been 
>> discussed yet is the drive towards making Swift a protocol oriented 
>> language.  IMO protocols should be the first tool considered when dynamic 
>> polymorphism is necessary.  Inheritance should be reserved for cases where 
>> other approaches won't work (and we should seek to reduce the number of 
>> problems where that is the case).  Making final the default for classes and 
>> methods would provide a subtle (or maybe not so subtle) hint in this 
>> direction.
>> 
>> I know the Swift team at Apple put a lot of thought into the defaults in 
>> Swift.  I agree with most of them. Enabling subclassing and overriding by 
>> default is the one case where I think a significant mistake was made.
> 
> Our current intent is that public subclassing and overriding will be locked 
> down by default, but internal subclassing and overriding will not be.  I 
> believe that this strikes the right balance, and moreover that it is 
> consistent with the general language approach to code evolution, which is to 
> promote “consequence-free” rapid development by:
> 
>  (1) avoiding artificial bookkeeping obstacles while you’re hacking up the 
> initial implementation of a module, but
> 
>  (2) not letting that initial implementation make implicit source and binary 
> compatibility promises to code outside of the module and
> 
>  (3) providing good language tools for incrementally building those initial 
> prototype interfaces into stronger internal abstractions.
> 
> All the hard limitations in the defaults are tied to the module boundary 
> because we assume that it’s straightforward to fix any problems within the 
> module if/when you decided you made a mistake earlier.
> 
> So, okay, a class is subclassable by default, and it wasn’t really designed 
> for that, and now there are subclasses in the module which are causing 
> problems.  As long as nobody's changed the default (which they could have 
> done carelessly in either case, but are much less likely to do if it’s only 
> necessary to make an external subclass), all of those subclasses will still 
> be within the module, and you still have free rein to correct that initial 
> design mistake.

I think John summarized my position very well, so of course I'm going to come 
in here and add more stuff. :-)

In working on the design for library evolution support ("resilience"), we've 
come across a number of cases of "should a library author be able to change 
this when they release v2 of their library?" Many times, the answer is it's 
possible to do something in one direction, but not at all safe to go the other 
way. For example, you can always add public methods to a class, but you can't 
remove public methods because you don't know who's calling them. You can mark 
them deprecated, but that doesn't help with any client apps that have already 
been compiled and shipped.

One of the things that came up was "can you add 'final' to a class?" And of 
course you can't, because you don't know who may have already subclassed it. 
That's very unfortunate for a library author who simply forgot to add 'final' 
when they were first writing the class.

The interesting thing about this is that the "error of omission"—of failing to 
think about whether a class should be final—is worse than the alternative. 
Ignoring optimizations for a 

Re: [swift-evolution] Final by default for classes and methods

[Rod Brown via swift-evolution]

Yeah, this really is a difficult one.

Adding final seems to be a risky thing at all, from a library or framework 
standpoint. As you say, there is hubris there in the suggestion “assume we’re 
right, and you can’t work around us.” I can see developer relations being 
inundated and unable to provide effective workarounds when the assumption is 
closed frameworks and finalised subclassing.

If they allow final in public frameworks, the default of “sealed” as mentioned 
by Jordan Rose makes sense. Closing an API further at a later date creates hell 
for those who subclass classes “hoping” that classes don’t become “finalised”. 
How do you handle such cases? It’s better than the alternatives.

But that suggests that indeed there is a greater problem here. Final in end 
products makes sense. It provides clarity, and allows optimisations. But in 
frameworks? For those who rely on the frameworks, the ability to subclass to 
avoid a bug, or to add functionality, while unintended and potentially unsafe, 
is something we use to develop apps, and how we inspire development of the 
framework. I think this risks stifling creativity and blocking effective 
workarounds to bugs.

If we are to add finalisation to API for frameworks, it makes sense to do 
“Sealed” by default as discussed. But perhaps it needs to be examined if we 
really want this aggressive optimisation and restriction on frameworks at all.



> On 20 Dec 2015, at 2:09 PM, Curt Clifton via swift-evolution 
>  wrote:
> 
> I'm not sure how many minuses I have to give, but I'd give them all to this 
> proposal.
> 
> Anyone who tries to ship products on release day of Apple's operating system 
> updates spends most of August and September writing horrible hacks so that 
> their users are insulated from OS bugs as much as possible. All software has 
> bugs, frameworks included. Please don't take away our tools for working 
> around those bugs. Making classes final by default assumes a level of 
> perfection on the part of framework developers that is not achievable.
> 
> Yes, subclassing a class that wasn't designed to be subclassed has serious 
> risks. Thoughtful developers sometimes take on those risks in order to serve 
> their customers.
> 
> Frankly, I think having `final` in the language at all is a mistake. While I 
> agree that we should prefer composition to inheritance*, declaring things 
> final is hubris. The only reasonable use case I've seen is for optimization, 
> but that smacks of developers serving the compiler rather than the converse. 
> Bringing an analog of NS_REQUIRES_SUPER to Swift would be most welcome; 
> that's as far as I'd go down the path of dictating framework usage.
> 
> Cheers,
> 
> Curt
> 
> *- and am thrilled with the property behaviors proposal for this use case
> 
> 
> On Dec 17, 2015, at 5:55 PM, Joe Groff via swift-evolution 
> > wrote:
> 
>> 
>>> On Dec 17, 2015, at 5:41 PM, Rod Brown via swift-evolution 
>>> > wrote:
>>> 
>>> My opinion is -1 on this proposal. Classes seem by design to intrinsically 
>>> support subclassing.
>>> 
>>> What if one framework provider thinks “you won’t need to subclass this 
>>> ever” but didn’t realise your use case for doing so, and didn’t add the 
>>> keyword? When multiple developers come at things from different angles, the 
>>> invariable situation ends with use cases each didn’t realise. Allowing 
>>> subclassing by default seems to mitigate this risk at least for the most 
>>> part.
>> 
>> Frameworks change, and if the framework author didn't anticipate your use 
>> case for subclassing, they almost certainly aren't going to anticipate it 
>> while evolving their implementation and will likely break your code. Robust 
>> subclassability requires conscious design just like all other aspects of API 
>> design.
>> 
>> -Joe
>> 
>>> I think this definitely comes under the banner of “this would be nice” 
>>> without realising the fact you’d be shooting yourself in the foot when 
>>> someone doesn’t add the keyword in other frameworks and you’re annoyed you 
>>> can’t add it.
>>> 
>>> 
 On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution 
 > wrote:
 
 Does it seem like there's enough interesest in this proposal? If so, what 
 would be the next steps? Should I go ahead and create a PR on the 
 evolution repo, describing the proposal version that Joe suggested, with 
 classes closed for inheritance by default outside of a module?
 
 Thanks!
 
 On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution 
 > wrote:
 I understand the rationale, I just disagree with it.
 
 IMO adding a keyword to state your intention for inheritance is not a 
 

Re: [swift-evolution] Final by default for classes and methods

[Curt Clifton via swift-evolution]

I'm not sure how many minuses I have to give, but I'd give them all to this 
proposal.

Anyone who tries to ship products on release day of Apple's operating system 
updates spends most of August and September writing horrible hacks so that 
their users are insulated from OS bugs as much as possible. All software has 
bugs, frameworks included. Please don't take away our tools for working around 
those bugs. Making classes final by default assumes a level of perfection on 
the part of framework developers that is not achievable.

Yes, subclassing a class that wasn't designed to be subclassed has serious 
risks. Thoughtful developers sometimes take on those risks in order to serve 
their customers.

Frankly, I think having `final` in the language at all is a mistake. While I 
agree that we should prefer composition to inheritance*, declaring things final 
is hubris. The only reasonable use case I've seen is for optimization, but that 
smacks of developers serving the compiler rather than the converse. Bringing an 
analog of NS_REQUIRES_SUPER to Swift would be most welcome; that's as far as 
I'd go down the path of dictating framework usage.

Cheers,

Curt

*- and am thrilled with the property behaviors proposal for this use case


> On Dec 17, 2015, at 5:55 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Dec 17, 2015, at 5:41 PM, Rod Brown via swift-evolution 
>>  wrote:
>> 
>> My opinion is -1 on this proposal. Classes seem by design to intrinsically 
>> support subclassing.
>> 
>> What if one framework provider thinks “you won’t need to subclass this ever” 
>> but didn’t realise your use case for doing so, and didn’t add the keyword? 
>> When multiple developers come at things from different angles, the 
>> invariable situation ends with use cases each didn’t realise. Allowing 
>> subclassing by default seems to mitigate this risk at least for the most 
>> part.
> 
> Frameworks change, and if the framework author didn't anticipate your use 
> case for subclassing, they almost certainly aren't going to anticipate it 
> while evolving their implementation and will likely break your code. Robust 
> subclassability requires conscious design just like all other aspects of API 
> design.
> 
> -Joe
> 
>> I think this definitely comes under the banner of “this would be nice” 
>> without realising the fact you’d be shooting yourself in the foot when 
>> someone doesn’t add the keyword in other frameworks and you’re annoyed you 
>> can’t add it.
>> 
>> 
>>> On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution 
>>>  wrote:
>>> 
>>> Does it seem like there's enough interesest in this proposal? If so, what 
>>> would be the next steps? Should I go ahead and create a PR on the evolution 
>>> repo, describing the proposal version that Joe suggested, with classes 
>>> closed for inheritance by default outside of a module?
>>> 
>>> Thanks!
>>> 
 On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution 
  wrote:
 I understand the rationale, I just disagree with it.
 
 IMO adding a keyword to state your intention for inheritance is not a 
 significant obstacle to prototyping and is not artificial bookkeeping.  I 
 really don't understand how this would conflict with "consequence-free" 
 rapid development.  It is a good thing to require people to stop and think 
 before using inheritance.  Often there is a more appropriate alternative.
 
 The assumption that it is straightforward to fix problems within a module 
 if you later decide you made a mistake is true in some respects but not in 
 others.  It is not uncommon for apps to be monolithic rather than being 
 well factored into separate modules, with many developers contributing and 
 the team changing over time.  While this is not ideal it is reality.
 
 When you have the full source it is certainly *possible* to solve any 
 problem but it is often not straightforward at all.  Here is an example of 
 a real-work scenario app developers might walk into:
 
 1) A class is developed without subclassing in mind by one developer.
 2) After the original developer is gone another developer adds some 
 subclasses without stopping to think about whether the original developer 
 designed for subclassing, thereby introducing subtle bugs into the app.
 3) After the second developer is gone the bugs are discovered, but by this 
 time there are nontrivial dependencies on the subclasses.
 4) A third developer who probably has little or no context for the 
 decisions made by previous developers is tasked with fixing the bugs.
 
 This can be quite a knot to untangle, especially if there are problems 
 modifying the superclass to properly support the subclasses (maybe this 
 breaks the contract the superclass has with its original