<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 Jan 30, 2017, at 12:36 PM, Robert Widmann 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="">This seems to contradict Swift’s goal of being <a href="https://swift.org/about/" class="">safe by default</a>, no?</div></div></div></blockquote><br class=""></div><div>IIUC, it wouldn’t contradict that goal <i class="">if</i> the compiler could guarantee that everything still gets initialized. I don’t know how that would work with classes that have private/fileprivate properties, though. If you’re subclassing something from the same project, the compiler could just look, but seeing as how exposing those things would kinda defeat the purpose, I don’t think there’s an existing mechanism for it to check 3rd party classes. Maybe we could add a flag to classes’ binary format indicating whether it’s possible for the compiler to infer if super.init() can be safely skipped?</div><div><br class=""></div><div>I don’t have a opinion yet on whether this proposal is a good idea… I’m just commenting on (my understanding of) Swift’s safety goals.</div><div><br class=""></div><div>- Dave Sweeris</div></body></html>