<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On 23 Mar 2017, at 16:49, Drew Crawford <<a href="mailto:drew@sealedabstract.com">drew@sealedabstract.com</a>> wrote:<br><br></div><blockquote type="cite"><div><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1490282999385896960" class="bloop_sign"></div> <br><p class="airmail_on">On March 23, 2017 at 2:22:20 AM, David Hart (<a href="mailto:david@hartbit.com">david@hartbit.com</a>) wrote:</p> <div><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><div><span style="color: rgb(0, 0, 0); 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;">> We will get static linking at some point in the near future.</span></div></span></blockquote></div><p>Static linking does not fix this issue. Just change "framework" to ".a".</p></div></blockquote><div>I'm curious to hear what issue your client had with you using many frameworks that static linking doesn't solve.</div><br><blockquote type="cite"><div><div><div><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-size-adjust: auto; -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;">> 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>Maybe submodules will solve this issue, maybe not. But submodules are *much* more complex than scoped access:</p><p>* 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>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"><div><div><p>* 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>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"><div><div><p>* 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>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"><div><div><p>* 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>* 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>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></div><div></div><div></div></div></blockquote><div>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></body></html>