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

[Ilya Belenkiy]

private means something different in OOP. Providing scoped access level and
calling it something other than private is good for backward compatibility,
but is not good for many people coming from other languages and who are
used to the OOP terminology (they would expect "scoped" to be "private".)

protected also means something different in OOP.

On Thu, Mar 31, 2016 at 9:54 PM Wallacy via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
> _______________________________________________
> 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/41477a96/attachment.html>