On Apr 11, 2017, at 10:30 PM, David Hart <da...@hartbit.com> wrote:
>> To me, the reason for limiting it to a file is about predictability, the
>> ability to locally reason about a type, and the need to define some boundary
>> (for symbol visibility reasons). Saying that extensions to a type have
>> access to private members if they are in the same module is just as
>> arbitrary as limiting it to a single file, and a whole lot less useful from
>> the “reasoning about a type” perspective.
>
> I think you misunderstand. We were talking about two extensions of a type, in
> a different file from the type, to share private members between themselves.
>
> Doug Gregor mentioned it during the PR process and we added an example to
> disallow it, but in hindsight, I think it should be allowed.
Ah, you’re saying:
a.swift:
struct X {}
b.swift:
extension X {
private func f() {}
}
extension X {
func g() { f() }
}
If so, then yes, I agree we should accept that.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
