<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">But with static linking, your user wouldn’t have to drag 4 .a libraries but only one, which contains all libraries statically linked together.</span></font></blockquote><div><br></div>Static linking is unrelated to merging modules. We can statically link libraries on Linux right now, this does not reduce the files on disk or reduce the number of statements required to import them etc. </div><div><br></div><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Those stats are misleading: an enormous majority of the search results concerning “duplicate symbol” concern incorrect build settings, not a wish to use different versions of the same code.</span></font></blockquote><br></div><div>This is inaccurate, the build settings are workarounds to the problem that different versions of the same code (or at least sharing the same C name) are in use. </div><div><br></div><div>Swift's visibility is not nearly as configurable as C'a from a build setting point of view, although we do have some (e.g. Test mode)</div><div><br></div><div><br></div><div><br><div>Sent from my iPhone</div></div><div><br>On Mar 23, 2017, at 6:52 PM, David Hart <<a href="mailto:david@hartbit.com">david@hartbit.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On 23 Mar 2017, at 21:49, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; 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; margin: 0px;" class=""><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px;"><div dir="auto" class="">I'm curious to hear what issue your client had with you using many frameworks that static linking doesn't solve.</div></blockquote><div style="font-family: Helvetica, Arial; font-size: 13px;" class=""><div dir="auto" class=""><br class=""></div></div><div dir="auto" style="font-family: Helvetica, Arial; font-size: 13px;" class="">The issue here is the number of frameworks that the user drags and drops into Xcode. Most libraries ship as a single framework, see<a href="https://www.mapbox.com/ios-sdk/" class=""><span class="Apple-converted-space"> </span>this page</a> for a typical example of what the installation documentation for this process generally looks like.</div><div dir="auto" style="font-family: Helvetica, Arial; font-size: 13px;" class=""><br class=""></div><div dir="auto" style="font-family: Helvetica, Arial; font-size: 13px;" class="">From a user POV, there is no difference between dragging 4 frameworks and dragging 4 .a libraries. Actually, the .a case is worse in Swift because in addition to object code (.a) we have .swiftmodule, .swiftdoc, and .modulemap. So that's a lot of files to drag.</div></div></div></blockquote><div><br class=""></div><div>But with static linking, your user wouldn’t have to drag 4 .a libraries but only one, which contains all libraries statically linked together.</div><br class=""><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; 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; margin: 0px;" class=""><div dir="auto" style="font-family: Helvetica, Arial; font-size: 13px;" class="">I have been involved in generating solutions for this problem in other areas (see the <a href="http://anarchytools.org/docs/atbin.html" class="">atbin standard</a> for example) but none of them are supported by Xcode.</div><div dir="auto" style="font-family: Helvetica, Arial; font-size: 13px;" class=""><br class=""></div><div dir="auto" style="font-family: Helvetica, Arial; font-size: 13px;" class="">Finally, static linking has nothing to do with visibility or the problems of exposing these frameworks as public API.</div><div dir="auto" style="font-family: Helvetica, Arial; font-size: 13px;" class=""><br class=""></div><div dir="auto" class=""><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;" class=""><div id="bloop_customfont" style="margin: 0px;" class=""><div dir="auto" class="">I don't see why submodules could not profit from WMO: the module is still compiled all together. Submodules are simply a scoping/hiding mechanism.</div></div><div id="bloop_sign_1490300347339394048" class="bloop_sign"></div></blockquote><br class=""></div><div dir="auto" class="">Then you will be surprised to hear that this is a subject of some debate. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021749.html" class="">Relevant thread.</a></div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;" class="">That looks like a very corner case. I haven't yet found myself in the case where I needed multiple versions of a code base in a same product (binary, framework, application)</blockquote></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">There are <a href="http://stackoverflow.com/search?q=duplicate+symbols" class="">253 pages</a> of search results for "duplicate symbol" on StackOverflow. Compare with <a href="http://stackoverflow.com/search?q=fileprivate" class="">48 pages</a> on fileprivate. It is quite clear which is the more complicated feature.</div></div></div></blockquote><div><br class=""></div><div>Those stats are misleading: an enormous majority of the search results concerning “duplicate symbol” concern incorrect build settings, not a wish to use different versions of the same code.</div><br class=""><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; 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; margin: 0px;" class=""><div dir="auto" class=""><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;" class=""><div dir="auto" class="">It would be very strange to me if they were independent libraries: what would different them from modules then?</div></blockquote><div class=""><div dir="auto" class=""><br class=""></div></div><div dir="auto" class="">The organization of object code on the filesystem does not necessarily have any relationship to "submodules the philosophical construct".</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;" class="">But at the same time, we can't write and review proposals with no regard for future proposals coming down the road or we end up with a clunky language.</blockquote></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I'm not aware of evidence any submodule proposal is actually coming. For example <a href="https://github.com/apple/swift/blob/master/docs/Modules.rst#id3" class="">here</a> is the only authoritative statement of the feature, "slated" for Swift 1.0 😆, a giant warning that we do not even have a design, and the doc mostly consists of questions for how the feature should work.</div></div></div></div></blockquote><div><br class=""></div><div>Well the community has definitely shown a LOT of interest in the topic during the last year. I’d be surprised if a proposal wouldn’t be put through review as soon as it’s “in scope”.</div><br class=""><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; 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; margin: 0px;" class=""><div dir="auto" class=""><div dir="auto" class="">A scoped access modifier on the other hand is a feature that was designed, is implemented, and is now widely used. What you are suggesting is we should throw it away because at any moment a bird could appear in the bush.</div></div></div></div></blockquote><div><br class=""></div><div>No. I’m suggesting we throw it away because I argue that it brings more confusion and complexity to the language than it solves problems. Again, I’m not saying you and other people don’t use it: we all have our own development experiences. But that hasn’t stoped us from removing features in the past. The submodule argument was just to mention that it would solve some of the same problems you are solving with scoped-private today.</div><br class=""><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; 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; margin: 0px;" class=""><div dir="auto" class=""><div dir="auto" class="">But we've waited for that bird for 3 releases. Rather, if that bird were to appear, we could then study whether or not it solves all the problems of the bird in our hand, or whether it does not. But that hypothetical is quite far from the present circumstance.</div></div></div><p class="airmail_on" style="font-family: Helvetica, Arial; font-size: 13px; 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;">On March 23, 2017 at 2:02:25 PM, David Hart (<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>) wrote:</p><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span class=""><div dir="auto" class=""><div class=""></div><div class=""><div class=""><br class=""></div><div class=""><br class="">On 23 Mar 2017, at 16:49, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><br class=""><div id="bloop_sign_1490282999385896960" class="bloop_sign"></div><br class=""><p class="airmail_on">On March 23, 2017 at 2:22:20 AM, David Hart (<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>) wrote:</p><div class=""><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; 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;"><div class=""><span class=""><span style="font-family: 'helvetica Neue', helvetica; font-size: 14px; 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; background-color: rgb(255, 255, 255); float: none; display: inline !important;" class="">> We will get static linking at some point in the near future.</span></span></div></blockquote></div><p class="">Static linking does not fix this issue. Just change "framework" to ".a".</p></div></blockquote><div class="">I'm curious to hear what issue your client had with you using many frameworks that static linking doesn't solve.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><blockquote type="cite" style="font-family: Helvetica, Arial; font-size: 13px; 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; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;" class="">> If we wait until we get submodules, we won't be able to revisit. This is probably our last chance to "remove" a feature. Submodules can always add features down the way.</blockquote></div><p class="">Maybe submodules will solve this issue, maybe not. But submodules are *much* more complex than scoped access:</p><p class="">* Performance. This is hot code we compile with WMO. Moving it into a submodule could reduce visibility for optimization in a way that causes a performance regression. In particular, we know that specialization of T is a performance requirement, it isn't clear whether that would be preserved. Does WMO provide the same visibility across submodules? Nobody knows.</p></div></div></blockquote><div class="">I don't see why submodules could not profit from WMO: the module is still compiled all together. Submodules are simply a scoping/hiding mechanism.</div><blockquote type="cite" class=""><div class=""><div class=""><p class="">* Namespacing. It's possible that one program may ship 3-4 versions of this code because each dependency has a slightly different version under our current samizdat process. It is not clear whether submodules would avoid the "duplicate symbols" issue from C/ObjC. Xiaodi seems quite concerned about a related "duplicate functions" problem involved with private today, doubling down on that is not a good idea.</p></div></div></blockquote><div class="">That looks like a very corner case. I haven't yet found myself in the case where I needed multiple versions of a code base in a same product (binary, framework, application)</div><blockquote type="cite" class=""><div class=""><div class=""><p class="">* It is not clear whether submodules are from an objectcode point of view merged into the parent library or kept as individual libraries</p></div></div></blockquote><div class="">It would be very strange to me if they were independent libraries: what would different them from modules then? No other language I've used works that way.</div><blockquote type="cite" class=""><div class=""><div class=""><p class="">* It is not clear from a .swiftmodule point of view whether submodules are merged into the parent module or distributed as .swiftmodules / .swiftdocs</p><p class="">* Not clear how much ABI impact there is from submodules at a time when we are supposed to be trying to stabilize it</p><p class="">I would love to believe that a proposal on submodules will come through having solutions to all these issues and many more, then we will implement it and all sing kumbayah. But we are a long distance from that, and it may never happen at all, certainly we cannot evaluate proposals that haven't been written. Meanwhile we have a solution in the hand.</p></div></div></blockquote><div class="">But at the same time, we can't write and review proposals with no regard for future proposals coming down the road or we end up with a clunky language.</div></div></div></span></blockquote></div></blockquote></div><br class=""></div></blockquote></body></html>