My 2c on access control regarding extensions + global variables: Another annoyance from SE-0025 was that "private" and "fileprivate" modifiers meant the same thing when dealing with extensions and global variables. Obviously this was for good reasons, but still seemed weird.
Regarding extensions now, I think it's nice that they actually can mean different things, so I definitely agree this is the right answer. I commonly mark extensions "private" simply to have the members inside default to that access level, rather than write "private" for each one. Now, should I have a collection of members that should be fileprivate, I can use a fileprivate extension for the same thing. Regarding global variables, however, I actually thing the current behavior should remain. A truly private global variable makes no sense, and so declaring fileprivate vs private should continue to have the same behavior. While a very logical argument could be made that we should just enforce "fileprivate" for such instances, I personally think this runs counter to progressive disclosure. A programmer should only have to learn about fileprivate when trying to share internals of a type with another type, and not when simply declaring a global variable. Playing devil's advocate, however, this might be a good thing. Now, when the programmer tries to declare a private global variable, they'll learn about the "fileprivate" modifier, and from that they'll learn what that does. So this would actually be a way of informing the programmer about fileprivate in the first place. Again, I think keeping private/fileprivate as functionally equivalent for global variables is "easiest", and it's what my vote is for. Additionally, as weird as it might be to have two access control levels that "do the same thing" in this case, I think it makes more sense than being unable to use "private" at all. But since there are valid arguments to enforce fileprivate, I won't argue too much :-) I strongly believe access control on extensions should remain, however, and that private/fileprivate should have different results. (Obviously, this doesn't affect public/internal modifiers) > On Apr 22, 2017, at 2:55 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Sat, Apr 22, 2017 at 4:05 PM, Jose Cheyo Jimenez <ch...@masters3d.com> >> wrote: >> >> >>> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>>> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>>> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> The "Access Control" section of the Swift 3 book says the following: >>>>>> You can mark an extension with an explicit access-level modifier (for >>>>>> example, private extension) to set a new default access level for all >>>>>> members defined within the extension. >>>>> The behavior of "private extension" in Swift 3 was a deviation from that >>>>> model, justified because "private" as a default would have meant that >>>>> nothing in the extension could ever be called. But it was still contrary >>>>> to the model suggested by the Swift documentation. >>>>> >>>>> Given the highly restrictive behavior of "private" in Swift 3 and the >>>>> documentation quoted above, it seems unlikely that a developer would >>>>> intentionally use "private extension" to mean "please make all this stuff >>>>> visible to the entire file"—it would have worked, but it seems an odd way >>>>> to write it. If that were the intention, I think "fileprivate extension" >>>>> would have been more likely. >>>>> >>>>> I think the change to the behavior of "private extension" is in line with >>>>> the model proposed by SE-0169, in line with the documented behavior of >>>>> access control on extensions, and in line with user expectations. >>>>> >>>>> -BJ >>>> >>>> I understand your point. Another aspect of SE-0169 is that fileprivate >>>> should be more rare and thus meaningful when used. The current behavior >>>> stays true to the goal of making fileprivate rare. >>>> >>>> A top level private scope is effectively fileprivate so it is not totally >>>> weird for the extension members to inherit the top level private scope. >>>> >>>> When extensions gain the ability to contain properties, we should not >>>> allow the access level modifiers to the extensions in the same way >>>> protocol extensions prohibit its use. >>> >>> That idea would be my preference too, but it has been already written up as >>> a proposal, considered, and rejected. >> >> Properties in extensions? AKA partials ? I was thinking disallow only when >> properties are introduced in the extension not in general. > > No, disallowing access modifiers on extensions. > _______________________________________________ > 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
