> On Jun 28, 2016, at 01:14, David Hart <da...@hartbit.com> wrote: > > Hello everybody, > > I tried using the access rules defined in SE-0025 in some code of mine to see > what effect it would have. I came out of the experiment more disappointed > than I thought. Here are several reasons: > > 1) The new rules make `private` more prominent compared to `fileprivate` (the > latter has a somewhat worse name). But at the same time, the Swift community > has developed a style of coding where a type is defined through a set of > extensions. To hide members from other types, but have access to them inside > the type extensions, we have often used `private` and placed the type and its > extensions in the same file. Because `private` is scoped, we are forced into > using `fileprivate` pervasively (which is uglier), using `internal` instead > (which is less safe) or moving the extension code into the type's scope > (which is against the way Swift code is being written today). All of these > options look worse to be than before SE-0025. > > 2) The new amended rules look complicated to me. I think they have the risk > of being confusing in practice, but we’ll have to see. > > More generally, I think that the scoping rules of `fileprivate` may have an > in insidious effect that favour moving code back into the type’s scope > instead of preferring the cleaner style of putting it into extensions. > > Potential solution: > > What is `private` members were also visible to all extensions of the type in > the same module?
I am strongly against this. Swift uses scope-based privacy; the new ‘private’ is still scope-based. Type-based privacy encourages extensions where none are needed and the right answer was ‘fileprivate’. Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
