<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>To what extent could your need for safety be satisfied by (a) giving the property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a very small unit test/shell script/Perl script which makes sure references to that very unique name only appear between the two "MARK:" comments?<br><br><div>-- </div><div>Brent Royal-Gordon</div>Sent from my iPhone</div><div><br>On Mar 23, 2017, at 10:11 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><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></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>