[swift-evolution] [swift-evolution-announce] [Review] SE-0025 Scoped Access Level

[David Owens II]

> On Feb 29, 2016, at 8:08 PM, Ilya Belenkiy <ilya.belenkiy at gmail.com> wrote:
> 
> 
> This is one interoperation. Here is another that makes it fit perfectly well:
> 
> - public: exports symbol to all files
> - internal: exports symbol to module files
> - private: exports symbol to one file containing the scope
> - scoped: no export

I disagree. The conceptual model is file scoping.

`public` - available in any source file within the module and in external source files that link the module
`internal` - available in any source file within the module
`private` - available in its own source file

The addition of `local` adds a new conceptual model around access control: lexical scoping. This type of scoping also actively works against various Swift patterns that are fairly common: using extensions to implement protocol conformance.

struct TypeA {
    var a: String
}

extension TypeA : StringLiteralConvertible {
    init(stringLiteral value: String) {
        self.a = value
    }
    
    init(extendedGraphemeClusterLiteral value: String) {
        self.a = value
    }
    
    init(unicodeScalarLiteral value: String) {
        self.a = value
    }
}

When `a` on type `TypeA` is declared as `local`, this pattern is no longer possible. Thus I find the use cases for `local`, as presented in the proposal, extremely limited in real use cases. 

Now, if the proposal was to have `local` be scoped to the type that defines it, thus allowing extensions access to it, then it becomes more interesting, and has many more applicable use cases while still allowing the use case defined in the proposal.

-David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160301/2e8d0e7e/attachment.html>