[swift-evolution] access control

[Andrew Bennett]

It seems to be the opposite, these example work in a playground:

let public: Int = 123

error: keyword 'public' cannot be used as an identifier


However:

struct Test {

    private(set) var set: Int

}


no errors

I think that `module` and `file` without further context may be confusing.
I also think that `class` that I had is probably confusing.

I don't see the additional verbosity as a problem, I think the more
frequently used ones are probably fine.

I'm happy for them all to be keywords, the original proposal had some good
suggestions there, I just think what I've suggested is a bit nicer.

I think that what I'm suggesting would increase safety and granularity,
with only one new case you didn't have, and it would actually reduce the
number of keywords.


On Tue, Jan 26, 2016 at 1:51 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> 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> wrote:
>
>>
>> > On Jan 25, 2016, at 5:47 PM, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >
>> > on Mon Jan 25 2016, Ilya Belenkiy <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
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160126/6494ecf5/attachment.html>