[swift-evolution] access control

[Matthew Johnson]

> On Jan 25, 2016, at 8:37 PM, Andrew Bennett <cacoyi at gmail.com> wrote:
> 
> I like file scoped private, it's way better than C++'s `friend`. I also often feel that it's unsafe when I've mentally scoped implementation details to a class or extension, but the implementations are in the same file.
> 
> I would support something like this:
>     * `private(module)` alternatively `internal`, the default.
>     * `private` alternatively `private(file)`
>     * `private(class)`
>     * `private(extension)`
>     * `public`

I like the basic breakdown of functionality here, but why overload private with so many variations?  This is more verbose than necessary.  I think we can get away with being more clear and concise (access modifiers are decl modifiers, not keywords so they don’t steal identifiers, IIUC).

Why not this:

    * `public`
    * `module`, the default (currently `internal`).
    * `file` (currently `private`)
    * `private` (no current equivalent: containing scope whether class, struct, enum, extension, etc)

> 
> Perhaps this could let us deprecate/remove the keyword `internal`, I'm not sure of many circumstances when you'd actually need to write it.
> 
> I also think that `private(module)` is also more intuitively understood than `internal`.
> 
> My reasoning:
> 
> This seems to come down to:
> It lowers the cognitive load if you can put related concepts in the same file.
> It lowers the cognitive load if you can reduce the number of things a class needs to understand.
> People like the current system, its simple and it works for them.
> "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - The Elements of Programming Style
> 
> On Tue, Jan 26, 2016 at 12:46 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > On Jan 25, 2016, at 5:47 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> >
> > on Mon Jan 25 2016, Ilya Belenkiy <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >
> >>> Why should the compiler enforce this? That’s my design decision.
> >>
> >> It would enforce whatever design decision you make.
> >>
> >>> For the same reason the compiler does not enforce where I have to
> >>> put „private“ (it can make suggestions like many IDEs do and offer
> >>> fix-its, like „this method can be made private as it is not used
> >>> outside the class“ or „this class can be put into its own file as
> >>> its private methods are not used by other components in this file“.
> >>
> >> But once you do put it, it enforces it, and that’s the whole point of having access control.
> >>
> >>> No, there is a clear difference: making the type name part of the
> >>> variable name enforces no compiler checks whereas putting something
> >>> into different files does.
> >>
> >> Similarly, putting all of the source code in the same file is
> >> equivalent to no checks.
> >
> > The place where I'm most concerned about this is in playgrounds.  If
> > we're going to use them to teach programming, it should be possible to
> > demonstrate encapsulation there.
> >
> 
> Using playgrounds for teaching is a great example of a use case for this.  Thanks for mentioning it!
> 
> I also think the fact that “surrounding scope” is actually the most frequent use of `private` members (in code I have surveyed) indicates that it is a very reasonable feature request.  Allowing us to declare the actual intent aids readability and clarity.
> 
> -Matthew
> 
> > --
> > -Dave
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160125/1d202042/attachment.html>