[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart]

> On 23 Mar 2017, at 20:18, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> 
>> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> 
>> On 23 Mar 2017, at 16:49, Drew Crawford <drew at sealedabstract.com <mailto:drew at sealedabstract.com>> wrote:
>> 
>>> 
>>> 
>>> 
>>> On March 23, 2017 at 2:22:20 AM, David Hart (david at hartbit.com <mailto:david at 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.
> 
> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/51890498/attachment.html>