<div dir="ltr">So either open by default and sealed optionally or sealed by default and no escape hatch?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 11, 2016 at 6:20 PM, John McCall via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 10, 2016, at 6:42 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div dir="auto"><div><blockquote type="cite"><div><div><br></div><div><div><blockquote type="cite"><div>2016/07/09 23:30、Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>> のメール：</div><div></div></blockquote></div></div></div></blockquote></div></div></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><div dir="auto"><div><blockquote type="cite"><div><div><div><blockquote type="cite"><div><div style="word-wrap:break-word">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><div>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><div><br></div><div>Something like:</div><div><br></div><div>class MyFixedClass : @forceUnseal(SomeSealedClassThatNeedsFixing) { //Emits a scary compiler warning</div><div>}</div><div><br></div><div>Does that even seem feasible/possible, much less reasonable…?</div><div>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><br></div><div><span style="background-color:rgba(255,255,255,0)">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><br></div><div>My technical analysis: It’s certainly implementable to have the optimizer <i>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><br></div><div>(I’ll leave it at that, without trying to argue a particular side.)</div></div></div></div></blockquote><div><br></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></div><div>John.</div><div><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><br></div><div><br></div><blockquote type="cite"><div><div dir="auto"><div><blockquote type="cite"><div><div><div><div><div><div><div style="word-wrap:break-word"><div><div><br></div><div><div><blockquote type="cite">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><br>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></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><br></div><div>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></div><div>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><br></div><div>[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><div>Jordan</div></div><span class="">_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>