[swift-evolution] private & fileprivate

[Shawn Erickson]

I agree something like you suggest will give a lot of flexibility without -
I think - the IMHO quirkiness of friends in C++. It seems like the access
domains must? be limited to inside a module to avoid potential surprises
from outside the module?

-Shawn

On Sat, Oct 8, 2016 at 3:38 AM Karl via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
> personally I thought `private` was fine the way it was when it meant
> `fileprivate` and I had no real need for `private` as it exists in Swift 3.
>
>
> I have to agree with this; I wasn't especially comfortable with the change
> (or the eventual choice of keyword style) and in practice I just don't find
> it useful. I haven't used the new "private" even once since it was added,
> except by accident, the only form of private I use is fileprivate.
>
> I've happily embraced the conform through extension style in Swift, and
> really when it comes down to it the new private access level just isn't
> compatible with that style of development. It's only really useful for
> hiding details of something you add in one specific section, which I almost
> never do (and when I do I just mark it fileprivate in case I can re-use it).
>
> Maybe some people do find it useful, but I'd prefer fileprivate to be the
> default behaviour of private; the current (scoped?) private access level
> seems far more limited, thus more deserving of a less convenient keyword,
> or some kind of modifier on private. But personally I'd be fine with
> removing it, as I don't think it really adds anything that fileprivate
> doesn't already cover.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> Sometimes you have multiple types inside a single file (because you want
> to share some fileprivate stuff but not make it internal), so it’s handy
> for that.
>
> But you’re right that the syntax is totally ugly. I think access control
> is actually once of the biggest weak points of Swift - we should have a way
> for more arbitrary access control, similar to “friend classes” in C++. So
> then all of your types don’t need to be stuffed inside the same file in
> order to share semi-private implementation details. “Internal” is scoped to
> modules, but many people have also expressed the desire for sub-modules or
> namespaces and often resort to nasty things like caseless enums or empty
> structs (why nasty? because they don’t really define types - they’re just
> used for grouping purposes, and we should have a separate construct for
> that). So then we may need some way for these sub-modules to share some
> semi-private implementation details, etc…
>
> I would prefer if we could define some kind of access-domain, and you
> could assign members or types to those domains. We could possibly have some
> kind of user-defined access-domains, which you could opt-in to in order to
> see more details about a type (so you could expose it for subclassing
> purposes, like “protected”, or in any other more arbitrary way).
>
> So it might look something like:
>
> *@access-domain TabBarStuff* // the domain itself has an access-domain
>
> class TabController {
>     var tabs: [Tab]
>
>     *access(public)* func closeTab(at: Int) { … }
>     *access(TabBarStuff)* func close(tab: Tab) { … }
> }
>
> // Another file. Must be in the same module due to access-domain
> “TabBarStuff”’s visibility
>
> class Tab {
>    unowned var controller : TabController *access(TabBarStuff)*
>
>     func close() { *controller.close(tab: self)* }
> }
>
> In this case, our API design means that in TabController.close(tab:), we
> will never get a Tab from a different TabController. This is a nice feature
> to have, but it requires TabController and Tab to share a member which is
> not visible to other types. Currently, that means we must have types or
> extensions scattered around in different files to accommodate for access
> levels.
>
> Karl
> _______________________________________________
> 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/20161008/4abad887/attachment-0001.html>