[swift-evolution] Very limited scope for access control/(sub)modules in Swift 4
rjmccall at apple.com
Mon Mar 6 13:15:38 CST 2017
> On Mar 6, 2017, at 2:01 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
> One quick question:
> Nevin had a proposal that would remove ‘fileprivate' and redefine ‘private' to mean “private to the submodule” (which defaulted to file scope unless otherwise defined). This would be functionally equivalent to reversing 0025 (until submodules were added in a later version of swift). Would such a proposal be in scope for Swift 4, as it is really just defining semantics for future updates?
That seems like a reasonable way of thinking about things, but ultimately, distinctions without a difference are non-normative. If/when we introduce some concept of sub-modules, we'll have to consider what "private" and "internal" mean for them them. It's no good to pretend that it was settled in some discussion held at a time when it had zero language impact.
>> On Mar 6, 2017, at 9:31 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> Hi all,
>> Like everyone else in the Swiftverse, the core team recently spent some time discussing access control in Swift. While we love to see the enthusiasm on this topic, wholesale changes to the access control model—such as the introduction of submodules or a complete shift to a more type-centric access control model—are out of scope for Swift 4.
>> The core team does feel that a small part of this discussion—the reversal of SE-0025’s separation of “private” and “fileprivate”---is in scope for Swift 4, for which there is a proposal draft here:
>> - Doug
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution