> On 8 Oct 2016, at 11:31, Haravikk via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On 7 Oct 2016, at 22:44, Tony Allevato via swift-evolution
>> <swift-evolution@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
