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

[T.J. Usiyan]

public
internal
(fileprivate | interfile)
private

Either choice is fine with me

On Thu, Mar 31, 2016 at 11:33 AM, Jesse Squires via swift-evolution <
swift-evolution at swift.org> wrote:

> I really like this. +1 for the following:
>
> public
> internal
> fileprivate
> private
>
> -Jesse
>
> On Wed, Mar 30, 2016 at 9:22 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> 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
>>
>
>
>
> --
> Jesse Squires
>
> *blog* | jessesquires.com <http://www.jessesquires.com>
> *github* | github.com/jessesquires <http://www.github.com/jessesquires>
> *hexedbits* | hexedbits.com <http://www.hexedbits.com>
>
> _______________________________________________
> 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/20160331/e444a069/attachment.html>