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

[T.J. Usiyan]

I have many situations where related, and usually, nested types should have
access to implementation details of each other but I want to avoid any
other types having access to these details. The simplest example that I
have are value types that wrap one or two values. 'Unrelated' types
shouldn't have access to these `rawValue`s at all.
TJ


On Fri, Mar 25, 2016 at 12:11 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> These are special cases — both file-private and module-private is
> something that is fairly unusual
> >
> > afaics this is the third time someone mentions that "file-private" is
> uncommon — so I think it's time someone dissents:
> > That statement is at least subjective… right now, "file-private" is one
> of three access levels, and I wouldn't dare to say either is more or less
> important than the others.
> >
> > I never encountered situations with the current model where I missed a
> new "private"-level, and maybe "private" will become fairly unusual for the
> code I'll be writing.
> >
> > In my existing code, the new meaning of private wouldn't break much, but
> the current meaning doesn't hurt me, and there are cases where
> "file-private" is needed.
> >
> > None the less, I don't care much about the "ugliness" of "fileprivate" —
> but not because I perceive it as unusual:
> > I just expect that code completion will do the typing for me, so maybe
> "f" will be all I have to write (half the characters of "pr" ;-)
>
> I cannot come up with a single use-case in my code for fileprivate and
> would love
> some real world examples where you'd want visibility in a single file but
> not across
> an entire module.
>
> The fileprivate behavior has been a bugaboo of mine for some time,
> particularly in
> playground use.
>
> As far as I'm concerned, the control I really want is public,
> intra-modular, private, and
> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
>
> -- E
>
>
>
>
> _______________________________________________
> 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/20160325/8836f6f6/attachment.html>