<div dir="ltr">On Sun, Jul 10, 2016 at 10:38 PM, Jordan Rose via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a> ]<div><br></div><div>(This is my second response to this proposal. The previous message shared a use case where public-but-non-subclassable made things work out much better with required initializers. This one has a bit more ideology in it.)</div><div><br></div><div>As many people have said already, this proposal is quite beneficial to library designers attempting to reason about their code, not just now but in the future as well. The model laid out in the <a href="http://jrose-apple.github.io/swift-library-evolution/" target="_blank">Library Evolution document</a> (often referred to as “resilience”) supports Swift libraries that want to preserve a stable binary and source interface.</div><div><br></div><div>In the Swift 2 model (and what’s currently described in that document), a public class must be final or non-final at the time it is published. It’s clearly not safe to <i>add</i> ‘final' in a later version of the library, because a client might already have a subclass; it’s also not safe to <i>remove</i> ‘final’ because existing clients may have been compiled assuming there are no subclasses.</div><div><br></div><div>(Of course, we can remove this optimization, and make ‘final’ a semantic contract only. I’m deliberately avoiding most discussion of performance, but in this parenthetical I’ll note that Swift makes it possible to write code that is <i>slower</i> than Objective-C. This is considered acceptable because the compiler can often optimize it for a particular call site. For those who want more information about the current implementation of some of Swift’s features, I suggest watching the “<a href="https://developer.apple.com/videos/play/wwdc2016/416/" target="_blank">Understanding Swift Performance</a>” talk from this year’s WWDC.)</div><div><br></div><div>With this proposal, a public class can be non-publicly-subclassable or publicly-subclassable. Once a class is publicly-subclassable (“open”), you can’t go back, of course. But a class that’s not initially open could <i>become</i> open in a future release of the library. All existing clients would already be equipped to deal with this, because there might be subclasses <i>inside</i> the library. On the other hand, the class can <i>also</i> be marked ‘final’, if the library author later realizes there will never be any subclasses and that both client authors and the compiler should know this.</div><div><br></div><div>One point that’s not covered in this proposal is whether making a class ‘open’ applies retroactively, i.e. if MagicLib 1.2 is the first version that makes the Magician class ‘open’, can clients deploy back to MagicLib 1.0 and expect their subclasses to work? My inclination is to say no; if it’s possible for a non-open method to be overridden in the future, a library author has to write their library as if it will be overridden now, and there’s no point in making it non-open in the first place. That would make ‘open’ a “<a href="http://jrose-apple.github.io/swift-library-evolution/#publishing-versioned-api" target="_blank">versioned attribute</a>” in the terminology of Library Evolution, whatever the syntax ends up being.</div><div><br></div><div>---</div><div><br></div><div>Okay, so why is this important?</div><div><br></div><div>It all comes down to reasoning about your program’s behavior. When you use a class, you’re relying on the documented behavior of that class. More concretely, the methods on the class have preconditions (“performSegue(withIdentifier:sender:) should not be called on a view controller that didn’t come from a storyboard”) and postconditions (“after calling loadViewIfNeeded(), the view controller’s view will be loaded”). When you call a method, you’re responsible for satisfying its preconditions so it can deliver on the postconditions.</div><div><br></div><div>I used UIViewController as an example, but it applies just as much to your own methods. When you call a method in your own module—maybe written by you, maybe by a coworker, maybe by an open source contributor—you’re expecting some particular behavior and output given the inputs and the current state of the program. That is, you just need to satisfy its preconditions so it can deliver on the postconditions. If it’s a method in your module, though, you might not have taken the trouble to formalize the preconditions and postconditions, since you can just go look at the implementation. Even if your expectations are violated, you’ll probably notice, because the conflict of understanding is within your own module.</div><div><br></div><div>Public overriding changes all this. While an overridable method may have particular preconditions and postconditions, it’s possible that the overrider will get that wrong, which means the library author can no longer reason about the behavior of their program. If they do a poor job documenting the preconditions and postconditions, the client and the library will almost certainly disagree about the expected behavior of a particular method, and the program won’t work correctly.</div><div><br></div><div>"Doesn’t a library author have to figure out the preconditions and postconditions for a method anyway when making it public?" Well, not to the same extent. It’s perfectly acceptable for a library author to document stronger preconditions and weaker postconditions than are strictly necessary. (Maybe 'performSegue(withIdentifier:sender:)’ has a mode that can work without storyboards, but UIKit isn’t promising that it will work.) When a library author lets people override their method, though, they're promising that the method will never be called with a weaker precondition than documented, and that nothing within their library will expect a stronger postcondition than documented.</div><div><br></div><div><div>(By the way, the way to look at overriding a method is the inverse of calling a method: <i>you</i> need to deliver on the postconditions, and you can assume the <i>caller</i> has satisfied the preconditions. If your understanding of those preconditions and postconditions is wrong, your program won’t work correctly, just like when you’re calling a method.)</div></div><div><br></div><div>This all goes double when a library author wants to release a new version of their library with different behavior. In order to make sure existing callers don’t break, they have to make sure all of the library’s documented preconditions are no stronger and postconditions are no weaker for public API. In order to make sure existing subclassers don’t break, they have to make sure all of the library’s documented preconditions are no <i>weaker</i> and postconditions are no <i>stronger</i> for overridable API.</div><div><br></div><div>(For a very concrete example of this, say you’re calling a method with the type '(Int?) -> Int’, and you’re passing nil. The new version of the library can’t decide to make the parameter non-optional or the return value optional, because that would break your code. Similarly, if you’re <i>overriding</i> a method with the type ‘(Int) -> Int?’, and <i>returning</i> nil, the new version of the library can’t decide to make the parameter <i>optional</i> or the return value <i>non-</i>optional, because <i>that</i> would break your code.)</div><div><br></div><div>So, "non-publicly-subclassable" is a way to ease the burden on a library author. They should be thinking about preconditions and postconditions in their program <i>anyway,</i> but not having to worry about all the things a client might do for a method that <i>shouldn’t</i> be overridden means they can actually reason about the behavior—and thus the correctness—of their own program, both now and for future releases.</div><div><br></div><div>---</div><div><br></div><div>I agree with several people on this thread that non-publicly-subclassable-by-default is the same idea as internal-by-default: it means that you have to explicitly decide to support a capability before clients can start relying on it, and you are very unlikely to do so by accident. The default is “safe” in that a library author can change their mind without breaking existing clients.</div><div><br></div><div>I agree with John that even today, the entry points that <i>happen</i> to be public in the types that <i>happen</i> to be public classes are unlikely to be good entry points for fixing bugs in someone else's library. Disallowing overriding these particular entry points when a client already can't override internal methods, methods on structs, methods that use internal types, or top-level functions doesn’t really seem like a loss to me.</div><div><br></div><div>Library design is important. Controlling the public interface of a library allows for better reasoning about the behavior of code, better security (i.e. better protection of user data), and better maintainability. And whether something can be overridden is part of that interface.</div><div><br></div><div>Thanks again to Javier and John for putting this proposal together.</div><div>Jordan</div><div><br></div><div>P.S. There’s also an argument to be made for public-but-not-conformable protocols, i.e. protocols that can be used in generics and as values outside of a module, but cannot be conformed to. This is important for many of the same reasons as it is for classes, and we’ve gotten a few requests for it. (While you can get a similar effect using an enum, that’s a little less natural for code reuse via protocol extensions.)</div></div></blockquote><div><br></div><div>Would public-but-not-conformable protocols by default be the next step, then, in Swift's evolution?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>P.P.S. For those who will argue against “better security”, you’re correct: this <i>doesn’t</i> prevent an attack, and I <i>don’t</i> have much expertise in this area. However, I <i>have</i> talked to developers distributing binary frameworks (despite our warnings that it isn’t supported) who have asked us for various features to keep it from being <i>easy.</i></div></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></div>