> On Apr 15, 2017, at 2:01 AM, Manolo van Ee via swift-evolution 
> <[email protected]> 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

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to