<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><p style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</p><p style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</p><p style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">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.</p></div></blockquote></div>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.<div class="">You may not like that solution, but others might not even notice the difference. <br class=""><div class=""><div class="">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.</div><div class=""><br class=""></div><div class=""><div class="">We shouldn't overdramatise this question, and don't invent arguments to support partialities:</div><div class="">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.</div><div class=""><br class=""></div></div></div></div><div class="">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.</div></body></html>