[swift-evolution] Enhancing access levels without breaking changes
david at hartbit.com
Wed Apr 12 00:30:04 CDT 2017
> On 12 Apr 2017, at 07:16, Chris Lattner <clattner at nondot.org> wrote:
> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution <swift-evolution at 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.
More information about the swift-evolution