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

[Jonathan Tang]

On Tue, Mar 15, 2016 at 10:32 AM, Charles Kissinger via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > I, too, prefer it to be more like this:
> >
> > public  // unchanged
> > module  // currently internal
> > internal  // currently private
> > private  // new hotness
>
> I like these best out of what’s been suggested so far. I agree with those
> that think the parameterized versions are too long and unnecessary.
>
>
>
+1 to this as well.  "file" is fine instead of "internal" as well.  I don't
like the parameterized versions private(file) and private(module) because
they can get very verbose (I find I use file access all the time), and
because of the already-mentioned concerns about stacking with the
private(set) convention.


> >
> > l8r
> > Sean
> >
> >
> >> On Mar 14, 2016, at 7:50 PM, Jo Albright via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> +1
> >>
> >> I like this a lot. Name ideas : enclosed, filelocal, fileonly,
> filelock, fileaccess, fileprivate, insidefile, inner. I also like Erica’s
> filebound & file fixed.
> >>
> >> By Erica’s suggestion about switching…
> >>
> >> - public
> >> - modular, modulelock, packaged  (module only)
> >> - internal (file only)
> >> - private
> >>
> >> Designer . Developer .  Nerd
> >> Jo Albright
> >>
> >>
> >>> On Mar 14, 2016, at 8:18 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>> Per Doug’s email, the core team agrees we should make a change here,
> but would like some bikeshedding to happen on the replacement name for
> private.
> >>>
> >>> To summarize the place we’d like to end up:
> >>>
> >>> - “public” -> symbol visible outside the current module.
> >>> - “internal” -> symbol visible within the current module.
> >>> - unknown -> symbol visible within the current file.
> >>> - “private” -> symbol visible within the current declaration (class,
> extension, etc).
> >>>
> >>> The rationale here is that this aligns Swift with common art seen in
> other languages, and that many people using private today don’t *want*
> visibility out of their current declaration.  It also encourages “extension
> oriented programming”, at least it will when some of the other restrictions
> on extensions are lifted.  We discussed dropping the third one entirely,
> but think it *is* a useful and important level of access control, and
> when/if we ever get the ability to write unit tests inside of the file that
> defines the functionality, they will be a nicer solution to @testable.
> >>>
> >>> The thing we need to know is what the spelling should be for the third
> one.  Off hand, perhaps:
> >>>
> >>> fileprivate
> >>> private(file)
> >>> internal(file)
> >>> fileaccessible
> >>> etc
> >>>
> >>> Some other thoughts on the choice:
> >>> - this will be a declaration modifier, so it will not “burn” a keyword.
> >>> - if will be a uniquely Swift thing, so there is virtue in it being a
> googlable keyword.
> >>>
> >>> Thoughts appreciated.
> >>>
> >>> -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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160316/03cd4ff2/attachment.html>