> On 23 Mar 2017, at 16:49, Drew Crawford <[email protected]> wrote:
>
>
>
>
>> 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".
>
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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
