[swift-evolution] SE-0025: Scoped Access Level, next steps

[Wallacy]

I have to say, I'm not very happy with the progress of this topic ..
Let me explain:
I'm Swift user from day 1. A few weeks after, even with the limitations of
language, had an application in production.

One of the "cool" features that regularly use in my application is the
"file private" access level. Is very better (in practice) than C++
friendly, and enable a lot of different manners to think in our code design.

For example: I have a "hand shake" file, wen two specific types extension
knows about specift (and private) functions to do this "hand shake".

So, my problem is, after almost two years using Swift, "public", "internal"
and "private" is just "so obvious" and very easy to understand, change the
"old" private to something else is not very good.

I can understand the need to "more private" than current private, but who
need this feature?
* devs which do not want declare this "important" type in a different file.
* devs which want to declare more than one type per file to make some "
*friendly*" relationship, but not share some other specific information.
* devs which want to declare more than one type per file and *not* make any
relationship with these types different than public.

Also, I'm not expert, but the actual swift access control appear to enable
some good compiler optimizations, and works very well with top level
objects.

So my proposal is:

- *public* (do not change)
- *internal* (do not change)
- *private* (do not change)
- *protect* (new)

Why protect?

*First*, I believe that is a good word to identify a property that will be
accessed in a specific scope.
*Second*, it will only be used when the person declaring more than one type
in a single file and does not want to share any specific property. I think
this person opt to share the same file for more than one type, the "scope"
access control will be less used than current private (file based) because
a think there less "super private" properties between between those types
for the rest of the module.
*Third*, although I believe that Swift not need (and will not get) access
control only to subtypes, simply update this "protect" is enough (task for
another proposal). And even if the protect switch to "also" share
properties between subtypes, only those who want to put all subtypes in the
same file will lose.

Is impossible to make everyone happy anyway... And i think is good choose
the path which "extends" the rationale of the Swift access control over
these two years instead say "file based access control is now not so
important".



Em qui, 31 de mar de 2016 às 01:22, Chris Lattner via swift-evolution <
swift-evolution at swift.org> escreveu:

> On Mar 23, 2016, at 10:13 PM, Chris Lattner <clattner at apple.com> wrote:
> > How about we continue this trend, and follow other existing Swift
> keywords that merge two lowercase words (associatedtype, typealias, etc),
> and use:
> >
> >       public
> >       moduleprivate
> >       fileprivate
> >       private
> >
> > The advantages, as I see them are:
> > 1) We keep public and private meaning the “right” and “obvious” things.
> > 2) The declmodifiers “read” correctly.
> > 3) The unusual ones (moduleprivate and fileprivate) don’t use the
> awkward parenthesized keyword approach.
> > 4) The unusual ones would be “googable”.
> > 5) Support for named submodules could be “dropped in” by putting the
> submodule name/path in parens: private(foo.bar.baz) or
> moduleprivate(foo.bar).  Putting an identifier in the parens is much more
> natural than putting keywords in parens.
>
> I’ve seen a number of concerns on this list about moduleprivate, and how
> it penalizes folks who want to explicitly write their access control.  I’ve
> come to think that there is yes-another possible path forward here (which I
> haven’t seen mentioned so far):
>
> public
> internal
> fileprivate
> private
>
> The advantages, as I see them are:
> 1) We keep public and private meaning the “right” and “obvious” things.
> 2) The declmodifiers “read” correctly.
> 3) Compared to Swift 2, there is almost no change.  The only thing that
> changes is that some uses of Swift 2 “private” will be migrated to
> “fileprivate”, which makes the intent of the code much more clear.
> 4) fileprivate is the unusual and
> not-really-precedented-in-other-languages modifier, and it would still be
> “googable”.
> 5) The addresses the “excessively long” declmodifier problem that several
> people are concerned with.
> 6) Support for named submodules could be “dropped in” by parameterizing
> “internal”.
>
> Thoughts?
>
> -Chris
> _______________________________________________
> 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/20160401/5d8f14c8/attachment.html>