<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 27, 2017, at 2:57 AM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 27, 2017, at 11:35 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I don’t disagree with your overall point, but I do want to emphasize that forcing apps to bundle the stdlib and runtime is more than just suboptimal.</div></blockquote><br class=""></div><div class="">Wouldn't it be possible to have several versions of the runtime bundled with the OS? Frameworks on macOS still have a filesystem layout that is build around the idea of having several versions in one bundle.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I have personally thought about this as well, but it would also mean that the OS frameworks would need to come in several versions - imagine the following scenario:</div><div class=""><br class=""></div><div class="">Swift 4 libraries are included with macOS 10.13, some frameworks in the system link against them (e.g. AppKit).</div><div class=""><br class=""></div><div class="">Then, with macOS 10.14, Swift 5 comes along with ABI incompatible changes. AFAICT, if you want apps written compiled with Swift 4 to work under 10.14, you'll need:</div><div class=""><br class=""></div><div class="">- runtime libraries for Swift 4</div><div class="">- all system frameworks will need to contain two variants - one compatible with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable in the long run. For how long would you need to keep several versions of the framework around? What happens when Swift 6 comes along with another breaking changes? Would each system framework have 3 versions embedded?</div></div></div></div></blockquote><div><br class=""></div><div>That's right. If the OS frameworks use Swift then either (1) you have to clone the framework stack for each Swift version, or (2) you have only one copy of the frameworks but frameworks and apps can't share their Swift objects or publish Swift API.</div><div><br class=""></div><div>The framework structure that Apple inherited from NeXT supports framework versioning, but *no frameworks use it*. It doesn't scale. </div><div><br class=""></div><div>(NeXT used framework versioning a few times, back when the entire OS only had a handful of frameworks. Today's AppKit and Foundation are version C. libSystem is version B. That's about it.)</div><div><br class=""></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=""><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="">Also, breaking ABI isn't that uncommon: C++ did so in the past (and imho that language did things that are worse ;-)</div></div></div></blockquote></div></div></div></blockquote><br class=""></div><div>Note that Apple's OS frameworks do not export C++ interfaces. One reason was exactly that historically-unstable C++ ABI. Apple's OS developers chose #2 above for C++. OS frameworks and apps could get away with mismatched C++ ABI because they don't pass C++ objects to each other.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-- </div><div class="">Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>