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

[James Campbell]

What about private, fileonly, moduleonly, public ?

*___________________________________*

*James⎥Future Prime Minister*

*james at supmenow.com <james at supmenow.com>⎥supmenow.com <http://supmenow.com>*

*Sup*

*Runway East *

*10 Finsbury Square*

*London*

* EC2A 1AF *

On Thu, Mar 31, 2016 at 1:24 PM, Pierre Monod-Broca via swift-evolution <
swift-evolution at swift.org> wrote:

> I like :
>
> - public
> - modulewide or moduleprivate or internal
> - filewide or fileprivate
> - private
>
> I really dislike interfile because the word exists and means something else
> I dislike intermodule, inmodule and infile because I don't find them
> intuitive at all.
>
> I prefer the -wide flavors because they're shorter than the -private
> flavors, and because -wide is an existing suffix in english.
> Internal has the advantage of no modification but if we want to change it,
> now is the time.
>
>
> Le 31 mars 2016 à 11:10, Ross O'Brien via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> > public
> > internal
> > interfile
> > private
>
> Linguistically, I really like this direction. 'interfile' is one word, it
> reads as an adjective, it can be used in conversation (this has interfile
> visibility), and it's clear about where its visibility ends.
>
> It just doesn't mean what you think it means.
>
> 'inter' means 'between'. See: 'intergalactic', 'interstellar',
> 'international', 'internet'. So 'interfile' would have to mean 'visible
> between files' - i.e. an interfile symbol in one file is visible in another
> file. The prefix you're looking for, meaning 'internal', is 'intra' (see:
> 'intravenous', 'intranet').
>
> So the scale would become:
>
> public / intermodule
> internal / intramodule / interfile
> intrafile
> private
>
>
> On Thu, Mar 31, 2016 at 6:04 AM, Paul Ossenbruggen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> public
>> internal
>> interfile
>> private
>>
>> still googleable and very clear its scope and meaning, nice latin root.
>> Doesn’t overload “private”, slightly shorter.
>>
>>
>> > On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> > Looks good to me.
>> >
>> > -Thorsten
>> >
>> >> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution <
>> swift-evolution at swift.org>:
>> >>
>> >>> 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
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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/e9f9aa83/attachment.html>