> On Jun 28, 2016, at 22:16, Matthew Johnson <matt...@anandabits.com> wrote: > > >>> On Jun 28, 2016, at 9:06 PM, Jordan Rose via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Jun 28, 2016, at 19:03, Matthew Judge <matthew.ju...@gmail.com> wrote: >>> >>> Comments inline. >>> >>>> On Jun 28, 2016, at 04:14, David Hart via swift-evolution >>>> <swift-evolution@swift.org> 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. >>> >>> If I understand SE-0025 (even with the amendment) you can still spell the >>> access modifier to types as 'private' and get the same characteristics as >>> the pre-SE-0025 meaning or private, so I'm not sure I understand the >>> concern here. However (continued below) >>>> >>>> 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. >>>> >>> >>> I definitely agree that the amended rules look complicated. It seems to me >>> that the amended set of rules is favoring simplifying the implementation >>> over simplifying the mental model. >>> >>> My impression of what SE-0025 decided was that 'private' meant private to >>> the enclosing scope. If the access modifying 'private' was applied to a >>> type at the file scope, then it was synonymous with fileprivate and the >>> default access of members of that type should be fileprivate. >>> >>> If a inner type was declared private, than the default access of members of >>> that inner type should be private to the Outer type, not fileprivate. There >>> is currently no way of expressing this access explicitly, but it does not >>> seem like an especially useful thing to need to spell. >>> >>> Said in code, my impression of SE-0025 is that >>> >>> private class Outer { // exactly equivalent to fileprivate >>> var myVar = 0 // default: fileprivate >>> private class Inner { // private to Outer >>> var hiddenVar = 0 // default: private to Outer >>> private var reallyHiddenVar = 0 // default private to Inner >>> } >>> } >> >> This is definitely one of the considered alternatives. Both Brent and I >> didn’t like the idea of an access level that you couldn’t actually spell, >> and even if we got past that, we’d still need a way to refer to it in >> documentation and diagnostics. I would count that as a larger change than >> just allowing ‘fileprivate’ in places that previously would have been called >> redundant. > > This was really the fact that didn’t receive adequate attention during > discussion and review - that the semantics everyone understood it to have > implied visibility for members that you cannot state explicitly. It didn’t > bother me initially, but the diagnostics point Jordan makes is pretty > important (I think we could handle it ok in documentation). Good diagnostics > are extremely important and they must be both clear and concise. In order to > have good diagnostics we need a name for the visibility that everyone knows > so it may as well be part of the language. >
I don't want to reopen the bike shedding, but this issue was one of the main reasons I was in favor of the 'private(file)' spelling. 'private(Outer)', 'private(Inner)', etc. fall out as fairly obvious spellings for these cases in my mind. (The only big negative I see to those spellings is the potential for confusion for anyone too used to type-based access modifiers: that something marked 'private(Outer)' would not be visible in 'extension Outer {}') >> >> Jordan >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution