> On Mar 23, 2017, at 00:10, Drew Crawford via swift-evolution
> <[email protected]> wrote:
>
>> This fails to convince me.
I had similar thoughts.
> I understand that, but not why.
>
> 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.
>
I find this to be a somewhat convoluted motivation for the feature. This is a
shortcoming of tooling/workflow that shows itself in the presence of large
multi-framework Xcode projects. In other words, this use case seems fairly
distant from what was intended for private vs fileprivate.
I also found the earlier example you gave, of using private vs fileprivate to
create warnings on invalid access of thread state, to be stretching the access
control beyond what was intended. This sounds like a job for compiler static
analysis rather than access control.
-Matt
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
