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

[Goffredo Marocchi]

So either open by default and sealed optionally or sealed by default and no
escape hatch?

On Mon, Jul 11, 2016 at 6:20 PM, John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> 2016/07/09 23:30、Matthew Johnson <matthew at anandabits.com> のメール：
>
>
> This leaves the scenario of a case where you depend on a 3rd party,
> closed-source library written in Swift and where you cannot get (or use) a
> fix from the vendor for some reason.  This is a legitimate concern, but IMO
> it is not large enough to outweigh all of the advantages of making sealed
> the default.
>
> What are your thoughts on an ability for a way to force unseal a class
> that does need to be fixed, even if its temporary?
>
> Something like:
>
> class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) {
> //Emits a scary compiler warning
> }
>
> Does that even seem feasible/possible, much less reasonable…?
> Though it would have to be a perhaps separate discussion, this comes to my
> mind as becoming necessary down the road, but maybe I’m wrong...
>
>
> I'm not opposed to something like this in principle, but I'm not sure how
> it would work in practice.  There was some discussion of something along
> these lines on the list at one point (I think Joe Groff had some ideas).
> However, I don't think this is possible if the optimizer takes advantage of
> the sealed status when the library is compiled.  I'll leave it to the
> compiler experts to comment further on feasibility.
>
>
> My technical analysis: It’s certainly implementable to have the optimizer
> *not* take advantage of the sealed status, and to allow some sort of
> “unsafe-break-the-seal” syntax. We’d have to be sure that anything that
> “can’t possibly happen without external subclassing” still at least
> generates a deterministic trap rather than memory corruption, but that’s
> probably doable.
>
> (I’ll leave it at that, without trying to argue a particular side.)
>
>
> I agree that this is implementable.  I would be very reluctant to do it,
> though; it amounts to writing off all of the performance advantages of the
> proposal.  (And possibly the semantic advantages as well, like being less
> restrictive about required initializers.)
>
> John.
>
>
>
>
> I have seen some comments about nontrivial complexity in Apple’s
> frameworks caused by apps subclassing where they should not have (i.e.
> classes that would be sealed if it were possible in Objective-C).  This is
> extremely unfortunate and it impacts everyone on Apple’s platforms.
>
> I wish I had links handy for you, but I don’t recall exactly where or when
> this was mentioned and don’t have time to dig them up right now.
>
> I see, thats reasonable… if those links are available somewhere I would
> definitely like to see them, it would be a good education for me…
>
>
> IIRC like Jordan Rose may have made some comments along these lines either
> on list or on Twitter if you want to search, but that is a fuzzy memory and
> could easily be wrong.  :)
>
>
> I don’t have anything handy (partially because some of it isn’t public
> knowledge), but it’s a well-known phenomenon within Apple that new OSs
> break third-party apps in strange ways because they are relying on being
> able to swizzle a non-public selector, or even on its existence. I’ll admit
> I don’t hear as much about intrusive subclassing, but that doesn’t mean
> Apple hasn’t made changes that assume no one subclasses a particular class.
>
> [For anyone who doesn’t know the term “method swizzling”: Objective-C
> allows you to replace a class’s implementation of a method at run-time,
> regardless of where the class or the replacement is defined.]
>
> Jordan
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/8bcf06e0/attachment.html>