[swift-evolution] And another access control idea

[Brent Royal-Gordon]

> On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi All,
> 
> I’ve been following the access control discussion a little and I had an idea that I wanted to throw out here. I know it’s too late and the idea doesn’t provide source compatibility, but it seemed worthwhile to post it anyway. My apologies if something similar has already been proposed.
> 
> First of all, I propose to use a trailing colon ‘:’ to make it clear that it’s an access control keyword. Secondly, the idea introduces new keywords that clearly describe the scope of access:
> 
> scope:           (formerly private)
> file:            (formerly fileprivate)
> module:          (formerly internal, default)
> extern:          (formerly public)
> extern(open):    (formerly open)
> 
> Examples:
> extern: class SomePublicClass {            // explicitly public class
>     extern: var somePublicProperty = 0     // explicitly public class member
>     var someInternalProperty = 0           // implicitly internal class member
>     file: func someFilePrivateMethod() {}  // explicitly file-private class member
>     scope: func somePrivateMethod() {}     // explicitly private class member
> }
> 
> extern(open): class SomeOpenClass {        // explicitly open class
>     extern(open): func someOpenMethod() {} // explicitly open class member
> }
> 
> Having the keyword describe the access scope actually fits the access control model of Swift very well. The user doesn’t have to learn what public or private means, but only needs to know the concept. Especially coming from another programming language I think public and private are confusing and breaking with it will signal very clearly that the Swift model is different.
> 
> The idea is source breaking, but it’s very easy to deprecate the current syntax with a warning and automatically migrate, because:
> All keywords are redefined, so there can be no confusion with the current syntax.
> Only redefines the syntax, not the semantics.
> 
> Funny thing, I thought of this last night and when I woke up this morning I read Erica’s proposal that uses many of the same keywords, although in a different way. Telepathy? Or maybe we’re just onto something here?
> 
> I know this will turn everything upside down, but I like the overall consistency, so I just wanted to throw it into the group as the next idea to fix access controls and see if anyone likes it.
> 
> Alternatives considered:
> ‘all’ instead of ‘extern’. This sounds to me as if it can always be accessed from everywhere, which might not be what we want if we introduce submodules.

Approaches like this were evaluated and rejected even before we introduced strict source stability requirements. `extern(open)` undoes an important feature of the `public`/`open` design, which is that there's no syntactic penalty for opening a symbol. And the SE-0169 acceptance specifically stated there would be no more access control changes in Swift 4.

I don't think this is a viable suggestion.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170417/56e8203c/attachment.html>