> On 12 Apr 2017, at 07:16, Chris Lattner <clatt...@nondot.org> wrote: > > On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: >>>> I understand what you are saying and I wouldn't be against relaxing that >>>> requirement (not talking for Chris here). >>>> >>>> The model would change from "Types share scopes with their extensions in >>>> the same file the type was defined" to "Types and their extensions share >>>> the same scope in each file". >>> >>> Oh, I had missed that somehow. I agree that that is a very strange rule. >>> Do you know why it was proposed that way? >> >> We had to take a stance and Chris seemed to prefer the rule that was >> proposed. I didn't press because I'm sure he has reasons for preferring it >> that way. But I have a preference for generalizing visibility to all >> extensions, even to those in a different file than the type. > > 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. > Expanding it beyond a module would require a ton of stuff to be exported that > otherwise wouldn’t be, and would defeat a ton of optimization potential that > we can’t accept. > > -Chris > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
