I'm curious to hear what issue your client had with you using many frameworks
that static linking doesn't solve.
The issue here is the number of frameworks that the user drags and drops into
Xcode. Most libraries ship as a single framework, see this page for a typical
example of what the installation documentation for this process generally looks
like.
>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.
I have been involved in generating solutions for this problem in other areas
(see the atbin standard for example) but none of them are supported by Xcode.
Finally, static linking has nothing to do with visibility or the problems of
exposing these frameworks as public API.
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.
Then you will be surprised to hear that this is a subject of some debate.
Relevant thread.
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)
There are 253 pages of search results for "duplicate symbol" on StackOverflow.
Compare with 48 pages on fileprivate. It is quite clear which is the more
complicated feature.
It would be very strange to me if they were independent libraries: what would
different them from modules then?
The organization of object code on the filesystem does not necessarily have any
relationship to "submodules the philosophical construct".
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.
I'm not aware of evidence any submodule proposal is actually coming. For
example here 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.
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.
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.
On March 23, 2017 at 2:02:25 PM, David Hart (da...@hartbit.com) wrote:
On 23 Mar 2017, at 16:49, Drew Crawford <d...@sealedabstract.com> wrote:
On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
