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

Charles Srstka cocoadev at charlessoft.com
Wed Dec 23 13:23:56 CST 2015

> On Dec 23, 2015, at 1:12 PM, Felipe Cypriano via swift-evolution <swift-evolution at 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?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/5dd95fb0/attachment.html>

More information about the swift-evolution mailing list