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?

-- 
Brent Royal-Gordon
Sent from my iPhone

> On Mar 23, 2017, at 10:11 AM, Tino Heth via swift-evolution 
> <[email protected]> wrote:
> 
>> 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.
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to