<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 17, 2017, at 15:20, Ben Langmuir &lt;<a href="mailto:blangmuir@apple.com" class="">blangmuir@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Jordan,<div class=""><br class=""></div><div class="">First off, this is clearly the model we should have had all along ;-) &nbsp;That said, I have a concern about source-compat and our ability to automatically migrate code impacted by this change.<div class=""><blockquote type="cite" class=""><h2 style="box-sizing: border-box; margin-top: 24px; margin-bottom: 16px; line-height: 1.25; padding-bottom: 0.3em; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(234, 236, 239); color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; background-color: rgb(255, 255, 255);" class="">Source compatibility</h2><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; font-size: 16px; background-color: rgb(255, 255, 255);" class="">This makes existing code invalid in Swift 5, which is a source compatibility break.</p></blockquote><div class="">It's not just a source compatibility break, it's a break that cannot necessarily be fixed if you don't control the module that vended the struct. &nbsp;If a library doesn't expose an appropriate initializer, there is no way for the client to invent one. &nbsp;Similarly, this isn't going to be very amenable to automatic migration, since</div><div class="">a) there may not be a memberwise initializer to use</div><div class="">b) even if there is, it may change the semantics to use it</div><div class=""><br class=""></div><div class="">There are two classes that we could theoretically migrate automatically:</div><div class="">1) C structs, since we know the initializer and its semantics</div><div class="">2) when we are migrating the code that defines the struct at the same time</div><div class=""><br class=""></div><div class="">The latter case might be tricky though, since it requires more global knowledge than we have in today's migrator.</div><div class=""><br class=""></div><div class="">Any thoughts? &nbsp;Do we have an idea how common this is or what kinds of places it comes up in most often (in a single codebase with multiple modules vs external dependencies vs C structs vs ....)?</div></div></div></div></div></blockquote><br class=""></div><div>This is good to bring up, but I think "this can't be migrated" is the correct answer for Swift structs. It's equivalent in my mind to when someone was passing 'nil' to something that wasn't annotated for nullability and now is marked '_Nonnull': it's source-breaking, and what you had before might even have worked, but there's no guarantee that it would keep working in the future. That's harder to sell for multi-module projects or even test targets, though. I don't have a great answer there, but I don't think it's worth bending over backwards to handle the "I migrate everything at once" case.</div><div><br class=""></div><div>The C case is a bit harder to sell, which is why I made sure there were fix-its to suggest inserting `self.init()` (the zeroing initializer) in most cases (both in Swift 4 mode and Swift 5 mode). Not all C structs <i class="">have</i>&nbsp;that initializer (specifically, if they have a member marked _Nonnull), but nearly all do, and that's something the migrator could insert fairly easily, as you note.</div><div><br class=""></div><div>The mitigating factor I'm hoping for is that these become warnings in Swift 4.1, which is planned to ship in a mid-year Xcode (can I admit that publicly, swift-evolution?), and that therefore many people will have cleaned up their code well before they even think of switching to Swift 5. But yes, this is a breaking, non-migratable language change that's only strictly necessary for libraries with binary compatibility, which most libraries today are not, and that has to be acknowledged.</div><div><br class=""></div>Jordan</body></html>