[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels
Tino Heth
2th at gmx.de
Thu Mar 23 12:11:34 CDT 2017
> I can't go into detail in public, but I can say that we did a postmortem on a large lost sale and the customer specifically cited the number of frameworks in our product as an integration barrier for them. Most iOS SDKs are distributed as a single framework and so with that backdrop the friction makes more sense.
>
> As a result of that I have about 5 bugs open on how to reduce our framework footprint so our tools are easier for our users to integrate. There are a variety of solutions we use on that, what you see here is one of the saner ones, believe it or not.
>
> Whether or not the technical requirement makes sense to you, the business case is very clear. So clear that if scoped were removed we would almost certainly keep the file and its potential threading bugs, over promoting a new framework. Sales >> code, unfortunately.
>
Oh, come on — that sounds like removing new private would threaten your existence… in this case, afaics a simple search & replace (private -> fileprivate) works just fine.
You may not like that solution, but others might not even notice the difference.
Imho the importance of SE-25 has been exaggerated tremendously before it was added, and the same seems to happen now, when its removal is discussed.
We shouldn't overdramatise this question, and don't invent arguments to support partialities:
Access control worked fine in Swift 2, and fileprivate didn't increase the complexity of the language in a way that makes it impossible to teach it.
There are arguments for both positions, and they are valid — but there is a huge variance in the perceived importance, and discussion has only very limited effect on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170323/901c2eb2/attachment.html>
More information about the swift-evolution
mailing list