[swift-evolution] private & fileprivate

Sat Oct 8 17:58:10 CDT 2016

Very much agree with essentially all of that.

Personally, I'd also want to explore whether any submodule scope could just
subsume fileprivate (i.e., files not otherwise in a submodule behave as
though they are their own submodule for access control purposes) rather
than occupy another slot between it and internal, but that's a discussion
we can postpone until a submodule proposal takes shape.

On Sat, Oct 8, 2016 at 17:27 Matthew Johnson <matthew at anandabits.com> wrote:

>
>
> Sent from my iPad
>
> On Oct 8, 2016, at 3:24 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Sat, Oct 8, 2016 at 2:15 PM, Matthew Johnson <matthew at anandabits.com>
> wrote:
>
>
> On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On 8 Oct 2016, at 16:47, Braeden Profile <jhaezhyr12 at gmail.com> wrote:
>
>
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I was thinking that the domains themselves could be associated with a
> domain, so you could create alternate domains which are also
> publicly-visible, but distinct from the default, “public” domain.
>
> For example, if you have a bunch of methods which should be visible to
> subclasses, but you don’t want them to clutter your regular interface.
> Perhaps they have names which are confusingly-similar to the public API. I
> believe that is what “protected” is typically used for.
>
>
> Yes, but “protected" was specifically put down by the core team, seeing
> that any code from outside the library should see the class as one
> well-designed whole, not something with complicated, visible implementation
> details.  If your class-internal methods are confusing (and aren’t
> necessary for normal use), they shouldn’t be made public in any way.
> Subclasses would too easily confuse the distinction between your
> implementation methods and your public ones.
>
> For what it’s worth, I was only confused by “private” and “fileprivate”
> for a minute or two until I looked up the actual proposal.  I haven’t had
> trouble with it, and it does actually provide more flexibility for code
> access at the file level than we had before.  Even if the syntax is clunky.
>
>
> I’m not saying that (file)private is confusing - it’s very clear about
> what it does. But it is limiting; anything that wants access to those
> semi-private details needs to live in the same file. That’s clearly not
> scalable. Enormous files many thousands of lines long are easy for the
> compiler to digest, but less easy for humans to understand and navigate. In
> fact, I believe this whole “file-based” access control originally came out
> of the compiler’s implementation details.
>
>
> I'm interested in more information about this. What sorts of code have you
> been writing where a file would have to be thousands of lines long in order
> to accommodate `fileprivate`? Many entire modules are only thousands of
> lines long--is there a reason this code couldn't be refactored into a
> module of its own? As mentioned by Matthew, isn't this calling for some
> notion of submodules?
>
>
> There are rather significant optimization barriers at module boundaries
> right now.  These do not exist for the standard library due to its tight
> relationship with the compiler, but for the moment it is a non-trivial
> concern for 3rd party code that is performance sensitive.  This is
> effectively a language pressure in the direction of larger modules, at
> least for some domains.  (Hopefully this pressure will eventually be
> alleviated - there has been at least some talk in that direction)
>
>
> Great point. IMO, it'd be important to identify how much of the desire for
> additional varieties of access modifiers represent workarounds to compiler
> limitations, because we'd be better off making optimization across module
> boundaries work better if that's the root of the issue. Certainly, also,
> submodules are a discussion that, having made a brief appearance at the end
> of Swift 3 evolution, would be ripe for Swift 4 phase 2.
>
> As for this topic about additional access modifiers, I'd like to
> understand what current use cases motivate them that arise because the
> current syntax is insufficiently expressive, rather than compiler
> shortcomings or the lack of other features that are on the horizon. The
> latter sorts of motivation, IMO, would be more definitively addressed by
> tackling the root problem; adding additional syntax in order to work around
> compiler limitations seems as best inelegant.
>
>
> I agree completely.  We definitely don't want to add features motivated
> only by current limitations.
>
> IMO there is plenty of motivation for submodules from a number of
> different angles.  If we do add them I think allowing an access control
> distinction between submodule and whole module makes a lot of sense.   That
> isn't sufficient motivation on its own of course, but is still very
> relevant to any discussion of any access level between fileprivate and
> internal.  I also believe it is very likely to be the best and most natural
> solution.
>
> That said, it's always good to keep pushing for better concrete examples
> and use cases.
>
> As for the cross-module performance issue, I very much hope to see that
> solved independent of any new features (aside from perhaps some annotations
> that help the optimizer and give it more room to work by restricting our
> future options for change).
>
>
>
>
> What it would basically come down to is that the interface of the object
> would be separated in to blocks based on your access privileges. When
> viewing the interface, it wouldn’t look much different to an extension:
>
> *access(public)* class TabController {
>    var tabs : [Tab] { get }
>    func closeTab(at: Int)
> }
>
> *access(TabBarStuff)* extension TabController {
>     func close(tab: Tab)
> }
>
> I definitely want something between internal and fileprivate, at least. I
> don’t see any reason at all why objects shouldn’t be allowed to present
> optional “slices” of their interface to appropriate clients. In fact, that
> is what access control is all about. I just want to generalise it to allow
> for user-defined visibility scopes (as well as the default ones for public,
> module, file and scope). That leads to the question of what visibility
> those user-defined scopes would have; and if you leave them entirely open
> to adopt any scope (except themselves), then you end up with the ability to
> slice your API for different use-cases. Or we could be boring and limit
> them to the module they are defined in.
>
> The whole reason I’m bringing this up is because I don’t like the “file”
> part of fileprivate. How I split my files up is a readability decision.
>
> Karl
>
> _______________________________________________
> 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/20161008/c8a82c61/attachment.html>