On March 23, 2017 at 2:22:20 AM, David Hart ([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". > 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. * 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. * It is not clear whether submodules are from an objectcode point of view merged into the parent library or kept as individual libraries * 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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
