<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class=""><div class="">2016/07/09 23:30、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメール：</div><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""></div></blockquote></div></div></div></blockquote></div></div></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote></blockquote><blockquote type="cite" class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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. </div></div></blockquote><div class=""><div class="">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?<br class=""><div class=""><br class=""></div><div class="">Something like:</div><div class=""><br class=""></div><div class="">class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits a scary compiler warning</div><div class="">}</div><div class=""><br class=""></div><div class="">Does that even seem feasible/possible, much less reasonable…?</div><div class="">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...</div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I'm not opposed to something like this in principle, but I'm not sure how it would work in practice. </span>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. </div></div></div></blockquote><div class=""><br class=""></div><div class="">My technical analysis: It’s certainly implementable to have the optimizer <i class="">not</i> 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.</div><div class=""><br class=""></div><div class="">(I’ll leave it at that, without trying to argue a particular side.)</div></div></div></div></blockquote><div><br class=""></div>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.)</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><br class=""></div><div class=""><div class=""><blockquote type="cite" class="">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.<br class=""><br class="">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.<br class=""></blockquote>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…</div></div></div></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">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. :)</div></div></div></div></blockquote><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div 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.]</div><br class=""><div class="">Jordan</div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>