[swift-evolution] And another access control idea

[Manolo van Ee]

On Tue, 18 Apr 2017 at 04:56, Brent Royal-Gordon <brent at architechies.com>
wrote:

> 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:
>
>    1. extern: class SomePublicClass { // explicitly public class
>    2. extern: var somePublicProperty = 0 // explicitly public class member
>    3. var someInternalProperty = 0 // implicitly internal class member
>    4. file: func someFilePrivateMethod() {} // explicitly file-private
>    class member
>    5. scope: func somePrivateMethod() {} // explicitly private class
>    member
>    6. }
>
>
>
>    1. extern(open): class SomeOpenClass { // explicitly open class
>    2.
>
>
>    1. extern(open): func someOpenMethod() {} // explicitly open class
>    member
>    2. }
>
>
> 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
>

> I wasn't happy about 'extern(open)' either, but I liked the overall
consistency of the concept (at least for the other keywords) and hoped it
could be improved somehow.

Anyway, thanks for your response and sorry for the noise.

Regards,
Manolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170418/67e49457/attachment.html>