[swift-evolution] [Draft] Fix Private Access Levels

[Matthew Johnson]

Sent from my iPad

On Feb 21, 2017, at 4:40 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:

>> On Feb 20, 2017, at 10:58 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> The scoped keyword is a good choice not only because the community has been calling this feature “scoped access control” all along, but also because the principle underlying all of Swift’s access levels is the idea of a scope.
> 
> I think the second part of this sentence undermines the argument for `scoped` as a keyword: if *all* access levels are about scope, then *this* access level should not be called `scoped`, because the keyword should describe what's *different* about this access level.

I disagree Brent.  Maybe this statement will make more sense after I share my thoughts on how I want scope to work with submodules.

> 
> That's not to say "scoped" is a bad name, but I think it's good because the space inside curly braces can be thought of as a "scope". So I'd revise this sentence to something like:
> 
>    The scoped keyword is a good choice not only because the community has been calling this feature “scoped access control” all along, but also because a variable's scope is traditionally restrained to the curly-brace-delimited block the variable is declared in, and that's the behavior `scoped` implements.

This is true for lexical scoping, but I'd also like to see scoped be parameterized to take the name of a containing scope, such as a containing submodule.  This would be a powerful tool that allows sibling submodules to collaborate with each other.  It is similar to allowing extensions of different types collaborate within a file, but at a larger level of granularity.

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution