> On 23 Mar 2017, at 20:18, Matthew Johnson <[email protected]> wrote: > > >> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> On 23 Mar 2017, at 16:49, Drew Crawford <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> >>> >>> On March 23, 2017 at 2:22:20 AM, David Hart ([email protected] >>> <mailto:[email protected]>) wrote: >>> >>>> > We will get static linking at some point in the near future. >>> >>> Static linking does not fix this issue. Just change "framework" to ".a". >>> >> I'm curious to hear what issue your client had with you using many >> frameworks that static linking doesn't solve. >> >>>> > 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. >>> >>> Maybe submodules will solve this issue, maybe not. But submodules are >>> *much* more complex than scoped access: >>> >>> * 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. >>> >> 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. >>> * 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. >>> >> 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) >>> * It is not clear whether submodules are from an objectcode point of view >>> merged into the parent library or kept as individual libraries >>> >> 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. >>> * It is not clear from a .swiftmodule point of view whether submodules are >>> merged into the parent module or distributed as .swiftmodules / .swiftdocs >>> >>> * Not clear how much ABI impact there is from submodules at a time when we >>> are supposed to be trying to stabilize it >>> >>> 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. >>> >> 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. > > Or we can just wait until access control and / or submodules are part of a > release theme and address these issues more holistically.
Its worth asking the core team, but I have the impression that a submodule proposal (Swift 4+ now) will have much less leeway to remove features. So if we don’t remove scoped-based private now, we might not be able to remove it later, even if we wish we could. > As I have said before, the details of the submodule design we eventually end > up with could influence what problems people want access control to address > (or not address). It’s possible that we could end up with a design that > allows us to eliminate `fileprivate` instead of `private` if we feel we must > eliminate one of them. I have difficulties imagining a submodule proposal that could allow us to eliminate fileprivate. Care to give an example? > Right now we just don’t know enough to say for sure. > >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
