[swift-evolution] Type-based ‘private’ access within a file

[Shawn Erickson]

On Mon, Apr 3, 2017 at 8:38 PM Adam Knight via swift-evolution <
swift-evolution at swift.org> wrote:

> On Apr 3, 2017, at 8:11 PM, Nevin Brackett-Rozinsky via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> My remaining hope is that Swift will acquire a submodule design which
> renders “fileprivate” essentially redundant. If we get an access level that
> means “visible in a group of tightly-related files” and it has a concise
> spelling, then I will use that just about exclusively.
>
>
> You mean a namespace?  Ask some greybeard C++ developers how that one
> worked out.
>
> Honestly, regardless of names, I see the following needs:
>
> 1. Keep your mitts off this code, this is for me alone. You will break
> things if you change this.
> 2. This one is for me and my relatives who know what we're doing with it.
> 3. This is for my group as we work together on this problem.
> 4. This is for anyone that wants us to solve this problem for them.
> 5. This is for anyone that wants to try to solve this problem some other
> way.
>
> (private, protected, internal, public, open — perhaps?)
>
> What we call them matters little, as long as none of those names are
> fileprivate. 🙂  File-based access control is so very ‘70s (and this is
> coming from someone who has used C for a Very Long Time and loves it more
> than Swift, honestly). For *this* language, it’s the wrong tool.  We have
> those new-fangled hierarchical types and extensions all in those fancy
> little modules, so let’s use them as the people expect them to be used.
>
> When submodules are A Thing, revisit them in terms of the “definitions"
> above and see where things fit.  If we — heaven forbid — think we need an
> additional “export” keyword then we’ll have that firefight
>

Yeah basically my main objection to this proposed change and my general
dislike with current access controls is that they continue to depend on
file level scoping to provide for a functionality like "protected" in C++
(not that I exactly want that either, at least not friend). This forces you
to organize things in certain ways if you want to do anything more then
internal module level access.

I don't like the proposal primarily because it conflates file scope and
private scope which I think makes things more confusing and builds more on
the "crutch" of a file construct for access control. I much rather keep
things clear and explicit by requiring the use of fileprivate for those
situations instead of muddling up private (at least for now).

Instead I would want a protected like thing to be looked at that would
replace the need for fileprivate and that should be looked at in
conjunction with sub modules and likely properties, etc. ...let's spend out
energy on breaking away from file based access control. (that would make
playground better as well)

I feel most of the access controls levels in swift are well setup for
progressive disclosure... internal by default it great, you can get to work
without needing to know access controls. You can start to learn it by
putting your code in modules and dealing with public (and sometimes open)
which is great first way to understand the what and why of wanting to
control access to things. You can then start to learn about inter-module
encapsulation using private and then fileprivate.

-Shawn

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170404/3f24c092/attachment.html>