# Idea: Public Access Modifier Respected in Type Definition **URL:** \ **Category:** Discussion\ **Created:** [September 28, 2017, 4:17pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730 "2017-09-28T16:17:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![James\_Valaitis](https://avatars.discourse-cdn.com/v4/letter/j/7993a0/32.png) [@James\_Valaitis](https://forums.swift.org/u/James_Valaitis)\ **Post date:** [September 28, 2017, 4:17pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/1 "2017-09-28T16:17:37Z")
When declaring a public class or struct the properties still default to internal. ```swift public final class NewType { /// This property defaults to internal. var property: Any? } ``` This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension. ```swift public extension NewType { /// This function inherits the public modifier. func function() { } } ``` I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public. I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example: ```swift public struct Coordinate { /// Should default to public. let latitude: Double /// Should default to public. let longitude: Double /// Should default to public init?(latitude: Double, longitude: Double) { guard validate(latitude: latitude, longitude: longitude) else { return nil } … } } internal extension Coordinate { /// Convenience initialiser to me used internally within the module. init(coordinate: CLLocationCoordinate2D) { … } } private extension Coordinate { /// Private validation of the coordinate. func validate(latitude: Double, longitude: Double) -> Bool { … } } ``` This is legible and intuitive. The current behaviour is not. ---
**Author:** ![Jon\_Hull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_hull/32/678_2.png) [@Jon\_Hull](https://forums.swift.org/u/Jon_Hull)\ **Post date:** [September 29, 2017, 12:31am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/2 "2017-09-29T00:31:10Z")
+1000 This is the way it always should have worked… and it is the way my brain still expects it to work. All of the extraneous “Public”s clutter the code and make it much more difficult to read. Without it, the relatively few properties marked Internal or Private stand out. I know there is the argument about making people think about whether they want to expose each item… but it doesn’t work that way. Once you assign someone a rote task (assigning Public to most of the things), you lose the effect of having them think. From a cognitive psychology lens, when you give the brain a number of decisions to make in a row that are very similar, it will naturally make that task more efficient by automating as much of it as possible (i.e. thinking about it less). Mistakes become much more likely as a result. Tl;dr: Despite the myth/intention that the current setup makes you think about the problem more, it actually does the opposite and leads to an increased risk of error. Thanks, Jon > **···** > > > On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution \ wrote: > > > > When declaring a public class or struct the properties still default to internal. > > > > ```swift > > public final class NewType { > > /// This property defaults to internal. > > var property: Any? > > } > > > > ``` > > > > This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension. > > > > ```swift > > public extension NewType { > > /// This function inherits the public modifier. > > func function() { > > } > > } > > > > ``` > > > > I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public. > > > > I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example: > > > > ```swift > > public struct Coordinate { > > /// Should default to public. > > let latitude: Double > > /// Should default to public. > > let longitude: Double > > /// Should default to public > > init?(latitude: Double, longitude: Double) { > > guard validate(latitude: latitude, longitude: longitude) else { return nil } > > … > > } > > } > > internal extension Coordinate { > > /// Convenience initialiser to me used internally within the module. > > init(coordinate: CLLocationCoordinate2D) { > > … > > } > > } > > private extension Coordinate { > > /// Private validation of the coordinate. > > func validate(latitude: Double, longitude: Double) -> Bool { > > … > > } > > } > > > > ``` > > > > This is legible and intuitive. The current behaviour is not. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\ **Post date:** [September 28, 2017, 7:35pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/3 "2017-09-28T19:35:16Z")
No please no, the ship is long sailed for this one. I wish I didn‘t messed up my proposal last year and that we completely got rid of the access modifiers before the `extension` keyword. Huge -1 > **···** > > -- > Adrian Zubarev > Sent with Airmail > > Am 28. September 2017 um 19:44:25, James Valaitis via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb: > > > When declaring a public class or struct the properties still default to internal. > > > > ```swift > > public final class NewType { > > /// This property defaults to internal. > > var property: Any? > > } > > > > ``` > > > > This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension. > > > > ```swift > > public extension NewType { > > /// This function inherits the public modifier. > > func function() { > > } > > } > > > > ``` > > > > I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public. > > > > I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example: > > > > ```swift > > public struct Coordinate { > > /// Should default to public. > > let latitude: Double > > /// Should default to public. > > let longitude: Double > > /// Should default to public > > init?(latitude: Double, longitude: Double) { > > guard validate(latitude: latitude, longitude: longitude) else { return nil } > > … > > } > > } > > internal extension Coordinate { > > /// Convenience initialiser to me used internally within the module. > > init(coordinate: CLLocationCoordinate2D) { > > … > > } > > } > > private extension Coordinate { > > /// Private validation of the coordinate. > > func validate(latitude: Double, longitude: Double) -> Bool { > > … > > } > > } > > > > ``` > > > > This is legible and intuitive. The current behaviour is not. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Jon\_Hull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jon_hull/32/678_2.png) [@Jon\_Hull](https://forums.swift.org/u/Jon_Hull)\ **Post date:** [September 29, 2017, 1:05am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/4 "2017-09-29T01:05:19Z")
I should also mention that this is from a class of error where it becomes more likely with expertise. Thus, the more you do it, and get used to doing it, the more your brain will automate the task. You see this type of thing pretty often with nurses, for example. For anyone who would like a better understanding of the science behind designing to prevent errors, I recommend the book “Human Error” by James Reason. Also "The Design of Everyday Things" by Don Norman has a pretty good chapter on the basics, and is much more accessible. I really like that Swift attempts to do this! The use of forcing functions around optionals, for example, is brilliant. It is just that we are applying solutions rather haphazardly (without matching them to the underlying cause of error), and I think we can do better. That we are even considering these things is huge! I am just saying that there is an entire body of scientific research we can use to effectively accomplish this goal (and avoid known pitfalls)… we don’t have to reinvent the wheel. Thanks, Jon > **···** > > > On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution \ wrote: > > > > +1000 > > > > This is the way it always should have worked… and it is the way my brain still expects it to work. All of the extraneous “Public”s clutter the code and make it much more difficult to read. Without it, the relatively few properties marked Internal or Private stand out. > > > > I know there is the argument about making people think about whether they want to expose each item… but it doesn’t work that way. Once you assign someone a rote task (assigning Public to most of the things), you lose the effect of having them think. From a cognitive psychology lens, when you give the brain a number of decisions to make in a row that are very similar, it will naturally make that task more efficient by automating as much of it as possible (i.e. thinking about it less). Mistakes become much more likely as a result. > > > > Tl;dr: Despite the myth/intention that the current setup makes you think about the problem more, it actually does the opposite and leads to an increased risk of error. > > > > Thanks, > > Jon > > > > > On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution \\> wrote: > > > > > > When declaring a public class or struct the properties still default to internal. > > > > > > ```swift > > > public final class NewType { > > > /// This property defaults to internal. > > > var property: Any? > > > } > > > > > > ``` > > > > > > This is not the same for a public extension on the type, where then the access modifier is respected for any function or calculated property within the extension. > > > > > > ```swift > > > public extension NewType { > > > /// This function inherits the public modifier. > > > func function() { > > > } > > > } > > > > > > ``` > > > > > > I dislike this inconsistency, and I frequently find that when using my dynamic frameworks my code will not compile, and it will be due to my accidentally writing a public struct but not declaring the properties public. > > > > > > I believe in the idea that explicitly stating the access modifier leads to more legible code, but in my opinion it can be overdone, and I much prefer to explicitly state my intentions in the modifier on the definition or extension. For example: > > > > > > ```swift > > > public struct Coordinate { > > > /// Should default to public. > > > let latitude: Double > > > /// Should default to public. > > > let longitude: Double > > > /// Should default to public > > > init?(latitude: Double, longitude: Double) { > > > guard validate(latitude: latitude, longitude: longitude) else { return nil } > > > … > > > } > > > } > > > internal extension Coordinate { > > > /// Convenience initialiser to me used internally within the module. > > > init(coordinate: CLLocationCoordinate2D) { > > > … > > > } > > > } > > > private extension Coordinate { > > > /// Private validation of the coordinate. > > > func validate(latitude: Double, longitude: Double) -> Bool { > > > … > > > } > > > } > > > > > > ``` > > > > > > This is legible and intuitive. The current behaviour is not. > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\ **Post date:** [September 29, 2017, 12:55am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/5 "2017-09-29T00:55:46Z")
I don't want this to come across as though I'm trying to shut down discussion (because it's not my place to do so), but a significant amount of time was spent during the Swift 4 design phases debating how access levels should work, decisions were made, and I think many of us would like to move on and give time to other topics. I'd encourage you to look back through the archives and familiarize yourselves with the points made during that time. While it's always possible, I think it's unlikely that there will be new evidence introduced that would be so strong as to give the Swift team reason to, once again, make major source-breaking changes to access levels as late as Swift 5. > **···** > > On Thu, Sep 28, 2017 at 5:31 PM Jonathan Hull via swift-evolution \< swift-evolution@swift.org\> wrote: > > > +1000 > > > > This is the way it always should have worked… and it is the way my brain > > still expects it to work. All of the extraneous “Public”s clutter the code > > and make it much more difficult to read. Without it, the relatively few > > properties marked Internal or Private stand out. > > > > I know there is the argument about making people think about whether they > > want to expose each item… but it doesn’t work that way. Once you assign > > someone a rote task (assigning Public to most of the things), you lose the > > effect of having them think. From a cognitive psychology lens, when you > > give the brain a number of decisions to make in a row that are very > > similar, it will naturally make that task more efficient by automating as > > much of it as possible (i.e. thinking about it less). Mistakes become much > > more likely as a result. > > > > Tl;dr: Despite the\* myth\*/intention that the current setup makes you\* > > think about the problem more,\* it actually does the\* opposite\* and leads > > to an \*increased risk of error\*. > > > > Thanks, > > Jon > > > > On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > When declaring a public class or struct the properties still default to > > internal. > > > > ```swift > > public final class NewType { > > /// This property defaults to internal. > > var property: Any? > > } > > > > ``` > > > > This is not the same for a public extension on the type, where then the > > access modifier is respected for any function or calculated property within > > the extension. > > > > ```swift > > public extension NewType { > > /// This function inherits the public modifier. > > func function() { > > } > > } > > > > ``` > > > > I dislike this inconsistency, and I frequently find that when using my > > dynamic frameworks my code will not compile, and it will be due to my > > accidentally writing a public struct but not declaring the properties > > public. > > > > I believe in the idea that explicitly stating the access modifier leads to > > more legible code, but in my opinion it can be overdone, and I much prefer > > to explicitly state my intentions in the modifier on the definition or > > extension. For example: > > > > ```swift > > public struct Coordinate { > > /// Should default to public. > > let latitude: Double > > /// Should default to public. > > let longitude: Double > > /// Should default to public > > init?(latitude: Double, longitude: Double) { > > guard validate(latitude: latitude, longitude: longitude) else { return nil > > } > > … > > } > > } > > internal extension Coordinate { > > /// Convenience initialiser to me used internally within the module. > > init(coordinate: CLLocationCoordinate2D) { > > … > > } > > } > > private extension Coordinate { > > /// Private validation of the coordinate. > > func validate(latitude: Double, longitude: Double) -> Bool { > > … > > } > > } > > > > ``` > > > > This is legible and intuitive. The current behaviour is not. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![omochimetaru](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/omochimetaru/32/9598_2.png) [@omochimetaru](https://forums.swift.org/u/omochimetaru)\ **Post date:** [September 29, 2017, 2:12am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/6 "2017-09-29T02:12:28Z")
I am grad if it is accepted. I have two reasons. (1) I just recently confused visibility rule of extension which is different from class/struct. (2) I often write many classes in only one application target in project first. After code base grow, I often make new Framework target and move some classes into this for organizing dependency and improving modularity. At that time I need to write may `public` for classes and each func and vars. This is boring work. If I need to write `public` only once for each classes, It is very convenient. > **···** > > -- > omochimetaru > > 2017年9月29日(金) 10:05 Jonathan Hull via swift-evolution \< swift-evolution@swift.org\>: > > > I should also mention that this is from a class of error where it becomes > > more likely with expertise. Thus, the more you do it, and get used to > > doing it, the more your brain will automate the task. You see this type of > > thing pretty often with nurses, for example. > > > > For anyone who would like a better understanding of the science behind > > designing to prevent errors, I recommend the book \*“Human Error” \*by\* > > James Reason\*. > > > > Also \*"The Design of Everyday Things" \*by\* Don Norman\* has a pretty good > > chapter on the basics, and is much more accessible. > > > > I really like that Swift attempts to do this! The use of forcing > > functions around optionals, for example, is brilliant. It is just that we > > are applying solutions rather haphazardly (without matching them to the > > underlying cause of error), and I think we can do better. That we are even > > considering these things is huge! I am just saying that there is an entire > > body of scientific research we can use to effectively accomplish this goal > > (and avoid known pitfalls)… we don’t have to reinvent the wheel. > > > > Thanks, > > Jon > > > > On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > +1000 > > > > This is the way it always should have worked… and it is the way my brain > > still expects it to work. All of the extraneous “Public”s clutter the code > > and make it much more difficult to read. Without it, the relatively few > > properties marked Internal or Private stand out. > > > > I know there is the argument about making people think about whether they > > want to expose each item… but it doesn’t work that way. Once you assign > > someone a rote task (assigning Public to most of the things), you lose the > > effect of having them think. From a cognitive psychology lens, when you > > give the brain a number of decisions to make in a row that are very > > similar, it will naturally make that task more efficient by automating as > > much of it as possible (i.e. thinking about it less). Mistakes become much > > more likely as a result. > > > > Tl;dr: Despite the\* myth\*/intention that the current setup makes you\* > > think about the problem more,\* it actually does the\* opposite\* and leads > > to an \*increased risk of error\*. > > > > Thanks, > > Jon > > > > On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > When declaring a public class or struct the properties still default to > > internal. > > > > ```swift > > public final class NewType { > > /// This property defaults to internal. > > var property: Any? > > } > > > > ``` > > > > This is not the same for a public extension on the type, where then the > > access modifier is respected for any function or calculated property within > > the extension. > > > > ```swift > > public extension NewType { > > /// This function inherits the public modifier. > > func function() { > > } > > } > > > > ``` > > > > I dislike this inconsistency, and I frequently find that when using my > > dynamic frameworks my code will not compile, and it will be due to my > > accidentally writing a public struct but not declaring the properties > > public. > > > > I believe in the idea that explicitly stating the access modifier leads to > > more legible code, but in my opinion it can be overdone, and I much prefer > > to explicitly state my intentions in the modifier on the definition or > > extension. For example: > > > > ```swift > > public struct Coordinate { > > /// Should default to public. > > let latitude: Double > > /// Should default to public. > > let longitude: Double > > /// Should default to public > > init?(latitude: Double, longitude: Double) { > > guard validate(latitude: latitude, longitude: longitude) else { return nil > > } > > … > > } > > } > > internal extension Coordinate { > > /// Convenience initialiser to me used internally within the module. > > init(coordinate: CLLocationCoordinate2D) { > > … > > } > > } > > private extension Coordinate { > > /// Private validation of the coordinate. > > func validate(latitude: Double, longitude: Double) -> Bool { > > … > > } > > } > > > > ``` > > > > This is legible and intuitive. The current behaviour is not. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [September 29, 2017, 10:47am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/7 "2017-09-29T10:47:28Z")
> I don't want this to come across as though I'm trying to shut down discussion (because it's not my place to do so), but a significant amount of time was spent during the Swift 4 design phases debating how access levels should work, decisions were made, and I think many of us would like to move on and give time to other topics. > > I'd encourage you to look back through the archives and familiarize yourselves with the points made during that time. While it's always possible, I think it's unlikely that there will be new evidence introduced that would be so strong as to give the Swift team reason to, once again, make major source-breaking changes to access levels as late as Swift 5. Tony, while I do understand and support your opinion and don't support the idea of this pitch, don't you think we should fix the huge inconsistency with 'private extension'? private extension MyType {   /// This method have fileprivate access level, not private   func function() {...} } Such behavior had sense when extension was not able to keep private methods(who was able to see them then), but currently it is perfectly OK to have extension with only private methods in the same file with type. And one can really use 'fileprivate extension' if this is an intention. Existence of this inconsistency IMHO makes understanding of Swift access modifiers/levels even harder(especially for newcomers), adds point of confusion and even possible bugs(when code in same file accesses some method that really should be private), and removes a very useful feature to move some private methods to extensions. Thank you. Vladimir. > **···** > > On 29.09.2017 3:56, Tony Allevato via swift-evolution wrote: > > > On Thu, Sep 28, 2017 at 5:31 PM Jonathan Hull via swift-evolution \> \\> wrote: > > > >     +1000 > > > >     This is the way it always should have worked… and it is the way my brain still > >     expects it to work. All of the extraneous “Public”s clutter the code and make it > >     much more difficult to read. Without it, the relatively few properties marked > >     Internal or Private stand out. > > > >     I know there is the argument about making people think about whether they want to > >     expose each item… but it doesn’t work that way. Once you assign someone a rote > >     task (assigning Public to most of the things), you lose the effect of having them > >     think. From a cognitive psychology lens, when you give the brain a number of > >     decisions to make in a row that are very similar, it will naturally make that > >     task more efficient by automating as much of it as possible (i.e. thinking about > >     it less). Mistakes become much more likely as a result. > > > >     Tl;dr: \*\*Despite the\*myth\*/intention\*\*that the current setup makes you\*think > >     about the problem more,\* it actually does the\*opposite\* and leads to an > >     \*increased risk of error\*. > > > >     Thanks, > >     Jon > > > > >     On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution \>\> \\> wrote: > > > > > >     When declaring a public class or struct the properties still default to internal. > > >     ``` > > >     public final class NewType { > > >     /// This property defaults to internal. > > >     var property: Any? > > >     } > > >     ``` > > > > > >     This is not the same for a public extension on the type, where then the access > > >     modifier is respected for any function or calculated property within the extension. > > >     ``` > > >     public extension NewType { > > >     /// This function inherits the public modifier. > > >     func function() { > > >     } > > >     ``` > > > > > >     I dislike this inconsistency, and I frequently find that when using my dynamic > > >     frameworks my code will not compile, and it will be due to my accidentally > > >     writing a public struct but not declaring the properties public. > > > > > >     I believe in the idea that explicitly stating the access modifier leads to more > > >     legible code, but in my opinion it can be overdone, and I much prefer to > > >     explicitly state my intentions in the modifier on the definition or extension. > > >     For example: > > > > > >     ``` > > >     public struct Coordinate { > > >     /// Should default to public. > > >     let latitude: Double > > >     /// Should default to public. > > >     let longitude: Double > > >     /// Should default to public > > >     init?(latitude: Double, longitude: Double) { > > >     guard validate(latitude: latitude, longitude: longitude) else { return nil } > > >     … > > >     } > > >     internal extension Coordinate { > > >     /// Convenience initialiser to me used internally within the module. > > >     init(coordinate: CLLocationCoordinate2D) { > > >     … > > >     } > > >     private extension Coordinate { > > >     /// Private validation of the coordinate. > > >     func validate(latitude: Double, longitude: Double) -\> Bool { > > >     … > > >     } > > >     ``` > > > > > >     This is legible and intuitive. The current behaviour is not. > > > > > >     \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > >     swift-evolution mailing list > > >     swift-evolution@swift.org \ > > >     [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > >     \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > >     swift-evolution mailing list > >     swift-evolution@swift.org \ > >     [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [September 29, 2017, 5:42pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/8 "2017-09-29T17:42:09Z")
Vladimir, I agree with you on that change, but it’s a separate topic from this one. Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have. > **···** > > On Fri, Sep 29, 2017 at 05:47 Vladimir.S via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On 29.09.2017 3:56, Tony Allevato via swift-evolution wrote: > > \> I don't want this to come across as though I'm trying to shut down > > discussion > > \> (because it's not my place to do so), but a significant amount of time > > was spent > > \> during the Swift 4 design phases debating how access levels should work, > > decisions > > \> were made, and I think many of us would like to move on and give time to > > other topics. > > \> > > \> I'd encourage you to look back through the archives and familiarize > > yourselves with > > \> the points made during that time. While it's always possible, I think > > it's unlikely > > \> that there will be new evidence introduced that would be so strong as to > > give the > > \> Swift team reason to, once again, make major source-breaking changes to > > access levels > > \> as late as Swift 5. > > > > Tony, while I do understand and support your opinion and don't support the > > idea of > > this pitch, don't you think we should fix the huge inconsistency with > > 'private > > extension'? > > > > private extension MyType { > >         /// This method have fileprivate access level, not private > >         func function() {...} > > } > > > > Such behavior had sense when extension was not able to keep private > > methods(who was > > able to see them then), but currently it is perfectly OK to have extension > > with only > > private methods in the same file with type. > > And one can really use 'fileprivate extension' if this is an intention. > > Existence of this inconsistency IMHO makes understanding of Swift access > > modifiers/levels even harder(especially for newcomers), adds point of > > confusion and > > even possible bugs(when code in same file accesses some method that really > > should be > > private), and removes a very useful feature to move some private methods > > to extensions. > > > > Thank you. > > > > Vladimir. > > > > \> > > \> > > \> > > \> On Thu, Sep 28, 2017 at 5:31 PM Jonathan Hull via swift-evolution \> \> \\> wrote: > > \> > > \> +1000 > > \> > > \> This is the way it always should have worked… and it is the way my > > brain still > > \> expects it to work. All of the extraneous “Public”s clutter the > > code and make it > > \> much more difficult to read. Without it, the relatively few > > properties marked > > \> Internal or Private stand out. > > \> > > \> I know there is the argument about making people think about whether > > they want to > > \> expose each item… but it doesn’t work that way. Once you assign > > someone a rote > > \> task (assigning Public to most of the things), you lose the effect > > of having them > > \> think. From a cognitive psychology lens, when you give the brain a > > number of > > \> decisions to make in a row that are very similar, it will naturally > > make that > > \> task more efficient by automating as much of it as possible (i.e. > > thinking about > > \> it less). Mistakes become much more likely as a result. > > \> > > \> Tl;dr: \*\*Despite the\*myth\*/intention\*\*that the current setup makes > > you\*think > > \> about the problem more,\* it actually does the\*opposite\* and leads to > > an > > \> \*increased risk of error\*. > > \> > > \> Thanks, > > \> Jon > > \> > > \> > > \>\> On Sep 28, 2017, at 10:44 AM, James Valaitis via swift-evolution \> \>\> \\> \> wrote: > > \>\> > > \>\> When declaring a public class or struct the properties still > > default to internal. > > \>\> ``` > > \>\> public final class NewType { > > \>\> /// This property defaults to internal. > > \>\> var property: Any? > > \>\> } > > \>\> ``` > > \>\> > > \>\> This is not the same for a public extension on the type, where then > > the access > > \>\> modifier is respected for any function or calculated property > > within the extension. > > \>\> ``` > > \>\> public extension NewType { > > \>\> /// This function inherits the public modifier. > > \>\> func function() { > > \>\> } > > \>\> } > > \>\> ``` > > \>\> > > \>\> I dislike this inconsistency, and I frequently find that when using > > my dynamic > > \>\> frameworks my code will not compile, and it will be due to my > > accidentally > > \>\> writing a public struct but not declaring the properties public. > > \>\> > > \>\> I believe in the idea that explicitly stating the access modifier > > leads to more > > \>\> legible code, but in my opinion it can be overdone, and I much > > prefer to > > \>\> explicitly state my intentions in the modifier on the definition or > > extension. > > \>\> For example: > > \>\> > > \>\> ``` > > \>\> public struct Coordinate { > > \>\> /// Should default to public. > > \>\> let latitude: Double > > \>\> /// Should default to public. > > \>\> let longitude: Double > > \>\> /// Should default to public > > \>\> init?(latitude: Double, longitude: Double) { > > \>\> guard validate(latitude: latitude, longitude: longitude) else { > > return nil } > > \>\> … > > \>\> } > > \>\> } > > \>\> internal extension Coordinate { > > \>\> /// Convenience initialiser to me used internally within the module. > > \>\> init(coordinate: CLLocationCoordinate2D) { > > \>\> … > > \>\> } > > \>\> } > > \>\> private extension Coordinate { > > \>\> /// Private validation of the coordinate. > > \>\> func validate(latitude: Double, longitude: Double) -\> Bool { > > \>\> … > > \>\> } > > \>\> } > > \>\> ``` > > \>\> > > \>\> This is legible and intuitive. The current behaviour is not. > > \>\> > > \>\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > \>\> swift-evolution mailing list > > \>\> swift-evolution@swift.org \ > > \>\> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > \> > > \> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > \> swift-evolution mailing list > > \> swift-evolution@swift.org \ > > \> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > \> > > \> > > \> > > \> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > \> swift-evolution mailing list > > \> swift-evolution@swift.org > > \> [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > \> > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [September 30, 2017, 10:18pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/9 "2017-09-30T22:18:30Z")
Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability. -Chris > **···** > > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \ wrote: > > > > Vladimir, I agree with you on that change, but it’s a separate topic from this one. > > > > Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have. ---
**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [October 2, 2017, 10:25am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/10 "2017-10-02T10:25:28Z")
> > Vladimir, I agree with you on that change, but it’s a separate topic from this one. > > > > Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have. > > Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability. So we have to live with \*protected\* extension inconsistency for very long time just because core team don't want to even discuss \_this particular\_ inconsistency(when access level in \*private extension\* must be private, not fileprivate)? Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'. Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this) Vladimir. > **···** > > On 01.10.2017 1:18, Chris Lattner wrote: > > > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \ wrote: > > > -Chris ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [October 3, 2017, 12:33am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/11 "2017-10-03T00:33:10Z")
I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 \<[https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>); didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter. (I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.) I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.) Jordan > **···** > > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution \ wrote: > > > > On 01.10.2017 1:18, Chris Lattner wrote: > > > > > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \ wrote: > > > > > > > > Vladimir, I agree with you on that change, but it’s a separate topic from this one. > > > > > > > > Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have. > > > > > > Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability. > > > > So we have to live with \*protected\* extension inconsistency for very long time just because core team don't want to even discuss \_this particular\_ inconsistency(when access level in \*private extension\* must be private, not fileprivate)? > > > > Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'. > > > > Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this) ---
**Author:** ![masters3d](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@masters3d](https://forums.swift.org/u/masters3d)\ **Post date:** [October 3, 2017, 1:06am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/12 "2017-10-03T01:06:39Z")
I am not in favor of including a special case for “private extension” because like Jordan said, private is resolved at the level of the extension which is always top level currently. A change would make sense if we start allowing extensions that are not top level. Anything private that is top level is equivalent to fileprivate so why should “private extension” be any different? This is only confusing if people start mixing “fileprivate extension” and “private extension” in the same code base. We have a SwiftLint rule for this situation: [https://github.com/realm/SwiftLint/blame/master/Source/SwiftLintFramework/Rules/PrivateOverFilePrivateRule.swift](https://github.com/realm/SwiftLint/blame/master/Source/SwiftLintFramework/Rules/PrivateOverFilePrivateRule.swift) Alternatively you can enforce no extensions :) [https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/NoExtensionAccessModifierRule.swift](https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Rules/NoExtensionAccessModifierRule.swift) “"There is no solution that will make everyone happy: maintaining the status quo makes “fileprivate” too common and therefore not meaningful when it occurs in source;”" [https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html](https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html) > **···** > > > On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution \ wrote: > > > > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution \\> wrote: > > > > > > On 01.10.2017 1:18, Chris Lattner wrote: > > > > > > > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \\> wrote: > > > > > > > > > > Vladimir, I agree with you on that change, but it’s a separate topic from this one. > > > > > > > > > > Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have. > > > > > > > > Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability. > > > > > > So we have to live with \*protected\* extension inconsistency for very long time just because core team don't want to even discuss \_this particular\_ inconsistency(when access level in \*private extension\* must be private, not fileprivate)? > > > > > > Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'. > > > > > > Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this) > > > > I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 \<[https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>); didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter. > > > > (I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.) > > > > I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.) > > > > Jordan ---
**Author:** ![anandabits](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/anandabits/32/355_2.png) [@anandabits](https://forums.swift.org/u/anandabits)\ **Post date:** [October 3, 2017, 2:16am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/13 "2017-10-03T02:16:39Z")
> > > > Vladimir, I agree with you on that change, but it’s a separate topic from this one. > > > > > > > > Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have. > > > > > > Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability. > > > > So we have to live with \*protected\* extension inconsistency for very long time just because core team don't want to even discuss \_this particular\_ inconsistency(when access level in \*private extension\* must be private, not fileprivate)? > > > > Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'. > > > > Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this) > > I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter. I agree with this in principle but would not want to see it become a slippery slope back into extremely long access control discussions. > **···** > > Sent from my iPad > > > On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution \ wrote: > > > > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution \ wrote: > > > On 01.10.2017 1:18, Chris Lattner wrote: > > > > > > > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \ wrote: > > > (I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.) > > > > I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.) > > > > Jordan > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [October 3, 2017, 5:13am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/14 "2017-10-03T05:13:17Z")
Ok, I admit I just didn’t want to think about access control anymore after laster year’s excitement :-) That said, it seems that there is broad support for considering a refinement here, and I’m happy to get out of the way and let you guys make Swift better. :-) Thanks! -Chris > **···** > > On Oct 2, 2017, at 5:33 PM, Jordan Rose \ wrote: > > > > Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this) > > > > I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 \<[https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>); didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter. ---
**Author:** ![Nevin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nevin/32/617_2.png) [@Nevin](https://forums.swift.org/u/Nevin)\ **Post date:** [October 7, 2017, 5:17pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/15 "2017-10-07T17:17:48Z")
Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter. I would summarize the points on both sides as follows: For the change: • It is surprising to many people that members of a private extension are implicitly fileprivate. • There is currently no way to make an extension whose members default to private. Against the change: • The proposal is source-breaking. • The proposal makes “fileprivate” more common. • A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal breaks that symmetry. Notable questions: • Currently “open” cannot be applied to an extension at all, should we allow it? • Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work? Nevin ---
**Author:** ![jrose](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jrose/32/408_2.png) [@jrose](https://forums.swift.org/u/jrose)\ **Post date:** [October 3, 2017, 1:10am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/16 "2017-10-03T01:10:48Z")
It's fair to be against this change, but I want to point out that neither of these are "special cases". Instead it's "access is resolved at the level of extension and then applied to the member" vs. "access is applied to the members and then resolved". Jordan > **···** > > > On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez \ wrote: > > > > > On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution \\> wrote: > > > > > > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution \\> wrote: > > > > > > > > On 01.10.2017 1:18, Chris Lattner wrote: > > > > > > > > > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \\> wrote: > > > > > > > > > > > > Vladimir, I agree with you on that change, but it’s a separate topic from this one. > > > > > > > > > > > > Tony is absolutely correct that this topic has already been discussed. It is a deliberate design decision that public types do not automatically expose members without explicit access modifiers; this has been brought up on this list, and it is clearly not in scope for discussion as no new insight can arise this late in the game. The inconsistency with public extensions was brought up, the proposed solution was to remove modifiers for extensions, but this proposal was rejected. So, the final design is what we have. > > > > > > > > > > Agreed. The core team would only consider a refinement or change to access control if there were something actively broken that mattered for ABI stability. > > > > > > > > So we have to live with \*protected\* extension inconsistency for very long time just because core team don't want to even discuss \_this particular\_ inconsistency(when access level in \*private extension\* must be private, not fileprivate)? > > > > > > > > Yes, we decided that access level for extension will mean a default and top most access level for nested methods, OK. But even in this rule, which already differ from access modifiers for types, we have another one special case for 'private extension'. > > > > > > > > Don't you think this is not normal situation and actually there IMO can't be any reason to keep this bug-producing inconsistency in Swift? (especially given Swift 5 seems like is a last moment to fix this) > > > > > > I hate to say it but I'm inclined to agree with Vladimir on this. "private extension" has a useful meaning now distinct from "fileprivate extension", and it was an oversight that SE-0169 \<[https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>); didn't include a fix here. On this very narrow, very specific access control issue I think it would still be worth discussing; like Xiaodi said it's not related to James' original thread-starter. > > > > > > (I maintain that the current model does not include a special case; it simply means the 'private' is resolved at the level of the extension rather than the level of its members. But that isn't what people expect and it's not as useful.) > > > > > > I agree that changing the behavior of all access modifiers on extensions is out of scope. (I also agree that it is a bad idea. Sorry, James, but wanting 'pubic' here indicates that your mental model of extensions does not match what Swift is actually doing, and that could get you into trouble.) > > > > > > Jordan > > > > I am not in favor of including a special case for “private extension” because like Jordan said, private is resolved at the level of the extension which is always top level currently. A change would make sense if we start allowing extensions that are not top level. Anything private that is top level is equivalent to fileprivate so why should “private extension” be any different? ---
**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\ **Post date:** [October 3, 2017, 3:12am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/17 "2017-10-03T03:12:29Z")
> Sent from my iPad > > Vladimir, I agree with you on that change, but it’s a separate topic from > this one. > > Tony is absolutely correct that this topic has already been discussed. It > is a deliberate design decision that public types do not automatically > expose members without explicit access modifiers; this has been brought up > on this list, and it is clearly not in scope for discussion as no new > insight can arise this late in the game. The inconsistency with public > extensions was brought up, the proposed solution was to remove modifiers > for extensions, but this proposal was rejected. So, the final design is > what we have. > > Agreed. The core team would only consider a refinement or change to > access control if there were something actively broken that mattered for > ABI stability. > > So we have to live with \*protected\* extension inconsistency for very long > time just because core team don't want to even discuss \_this particular\_ > inconsistency(when access level in \*private extension\* must be private, not > fileprivate)? > > Yes, we decided that access level for extension will mean a default and > top most access level for nested methods, OK. But even in this rule, which > already differ from access modifiers for types, we have another one special > case for 'private extension'. > > Don't you think this is not normal situation and actually there IMO can't > be any reason to keep this bug-producing inconsistency in Swift? > (especially given Swift 5 seems like is a last moment to fix this) > > I hate to say it but I'm inclined to agree with Vladimir on this. "private > extension" has a useful meaning now distinct from "fileprivate extension", > and it was an oversight that SE-0169 > \<[https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>); didn't > include a fix here. On this \*very narrow, very specific \*access control > issue I think it would still be worth discussing; like Xiaodi said it's not > related to James' original thread-starter. > > I agree with this in principle but would not want to see it become a > slippery slope back into extremely long access control discussions. As I've said elsewhere, I too agree with this in principle. I agree with Jordan that the current state of things is justifiable but the alternative would be somewhat superior, agree that in a vacuum this very narrow and specific discussion might be warranted, and agree also that this could be a very slippery slide down a very steep slope. > **···** > > On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > On 01.10.2017 1:18, Chris Lattner wrote: > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > (I maintain that the current model does \*not\* include a special case; it > > simply means the 'private' is resolved at the level of the extension rather > > than the level of its members. But that isn't what people expect and it's > > not as useful.) > > > > I agree that changing the behavior of \*all\* access modifiers on > > extensions is out of scope. (I also agree that it is a bad idea. Sorry, > > James, but wanting 'pubic' here indicates that your mental model of > > extensions does not match what Swift is actually doing, and that could get > > you into trouble.) > > > > Jordan > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![masters3d](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@masters3d](https://forums.swift.org/u/masters3d)\ **Post date:** [October 7, 2017, 8:05pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/18 "2017-10-07T20:05:22Z")
> Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter. > > I would summarize the points on both sides as follows: > > For the change: > • It is surprising to many people that members of a private extension are implicitly fileprivate. > • There is currently no way to make an extension whose members default to private. > > Against the change: > • The proposal is source-breaking. > • The proposal makes “fileprivate” more common. > • A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal breaks that symmetry. Great summary! Thank you. > Notable questions: > • Currently “open” cannot be applied to an extension at all, should we allow it? > • Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work? This could be a solution that would not be source breaking to the topic at hand. extension MyType {     private extension {             // “true” private here         } } I think it would be a good idea to limit the nesting with other extensions. Other idea. extension { // bag of extensions     private extension MyType {             // “true” private here         }     fileprivate extension MyType2 {         // fileprivate here } } I rather have a comprehensive sub module system than nested extensions though. :) > **···** > > > On Oct 7, 2017, at 10:17 AM, Nevin Brackett-Rozinsky via swift-evolution \ wrote: > > > Nevin > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![VladimirS](https://avatars.discourse-cdn.com/v4/letter/v/f9ae1b/32.png) [@VladimirS](https://forums.swift.org/u/VladimirS)\ **Post date:** [October 9, 2017, 4:17pm UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/19 "2017-10-09T16:17:21Z")
> Two weeks ago I had a fairly strong opinion about “private extension” behavior. After following this discussion, I now have no opinion on the matter. > > I would summarize the points on both sides as follows: > > For the change: > • It is surprising to many people that members of a private extension are implicitly fileprivate. \> • There is currently no way to make an extension whose members default to private. I'd add this: \* Current rule for 'private extension' can lead to bugs, when you expect that private methods will be 'true' private but they are fileprivate, so could be called from not-expected code in the same file. Inverse situation(when you need fileprivate but 'private extension' means 'true' private) - can't cause bugs, you'll be notified by the compiler if you need a 'wider' access level. \* The change will make the access-control rule for extensions simpler, not harder to understand. \* 'fileprivate' access level for methods in extension will be used by \*intention\*, not just because "this is how 'private extension' works". If I understand correctly, it is not the 'fileprivate' \*keyword\* we want to see less, but the fileprivate \*access level\*, which should be rare and intentional. > Against the change: > • The proposal is source-breaking. > • The proposal makes “fileprivate” more common. It depends on what most of Swift developers \*mean\* when writing 'private extension' - if they actually need 'fileprivate extension' - then yes, we'll see it more in code. But if in most cases the \*intention\* is to have a bunch of 'true private' methods - we'll have a small number of 'fileprivate extension'. But in any case, what is the problem with this? If developer \*needs\* fileprivate access level for methods in extension - this will be clearly stated in code, not hidden under the cute title of 'private extension' > • A private extension and a (top-level) private type both currently have implicitly fileprivate members. The proposal breaks that symmetry. Is it really good symmetry? By definition, the rule for applying the access level to type is differ from the rule for extension. Here all symmetry already broken and we have 2 separate rules. And from my point of view, having a symmetry in \*this particular\* case is a bad thing, it can lead to wrong assumptions. Don't you want to apply the same 'symmetry' rule for the code below ? : public class C {      var i = 10 } public extension C {      func j(){} } ,as you understand 'i' is internal, while 'j()' is public. So this could be a dangerous assumption. > Notable questions: > • Currently “open” cannot be applied to an extension at all, should we allow it? Probably. But this should be a separate pitch/proposal. > • Might we ever want to allow nested (non-top level) extensions, and if so how should access levels on them work? Not sure if we need them, this is also a subject for separate pitch/proposal. But if the rule for applying the access level for extension will be as currently(I don't believe we'll change it soon) - nested extensions should work the same "the access level keyword stated before the 'extension' keyword will be virtually copy&pasted to the beginning of each method declaration inside extension and then resolved", IMO this is a most clear rule we can have \*in case rule for extensions is differ from rule for type". Vladimir. > **···** > > On 07.10.2017 20:17, Nevin Brackett-Rozinsky via swift-evolution wrote: > > > Nevin > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\ **Post date:** [October 3, 2017, 1:52am UTC](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730/20 "2017-10-03T01:52:18Z")
Thanks for hoisting this out into its own thread, Jordan. I was hesitant to elaborate more on another access level thread :) I think the change should absolutely be made. Even though the "private" keyword occurs at the file level, the description of the feature in the Swift documentation simply states: "you can mark an extension with an explicit access-level modifier to set a new default access level for all members defined within the extension." To me, that implies that "private extension Foo { func bar() }" should be identical to "extension Foo { private func bar() }", but today it becomes equivalent to "extension Foo { fileprivate func bar() }". That seems fundamentally broken, because (1) it's inconsistent, (2) "private extension" and "fileprivate extension" are two ways of saying the same thing, non-intuitively, and (3) there's no way for someone to use the shorthand syntax to take advantage of the new meaning of private within same-file type extensions. While I personally never use the shorthand extension access level feature (because I prefer the explicit form, and because of situations like this one), I definitely think it should be consistent for people who do want to use it. I wonder how much existing code would be affected by this change. Do people use "private extension" when they really want "fileprivate extension"? I would hope the number of users affected would be few, at least. > **···** > > On Mon, Oct 2, 2017 at 6:10 PM Jordan Rose via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez \ wrote: > > > > On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > On 01.10.2017 1:18, Chris Lattner wrote: > > > > On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > Vladimir, I agree with you on that change, but it’s a separate topic from > > this one. > > > > Tony is absolutely correct that this topic has already been discussed. It > > is a deliberate design decision that public types do not automatically > > expose members without explicit access modifiers; this has been brought up > > on this list, and it is clearly not in scope for discussion as no new > > insight can arise this late in the game. The inconsistency with public > > extensions was brought up, the proposed solution was to remove modifiers > > for extensions, but this proposal was rejected. So, the final design is > > what we have. > > > > Agreed. The core team would only consider a refinement or change to > > access control if there were something actively broken that mattered for > > ABI stability. > > > > So we have to live with \*protected\* extension inconsistency for very long > > time just because core team don't want to even discuss \_this particular\_ > > inconsistency(when access level in \*private extension\* must be private, not > > fileprivate)? > > > > Yes, we decided that access level for extension will mean a default and > > top most access level for nested methods, OK. But even in this rule, which > > already differ from access modifiers for types, we have another one special > > case for 'private extension'. > > > > Don't you think this is not normal situation and actually there IMO can't > > be any reason to keep this bug-producing inconsistency in Swift? > > (especially given Swift 5 seems like is a last moment to fix this) > > > > I hate to say it but I'm inclined to agree with Vladimir on this. "private > > extension" has a useful meaning now distinct from "fileprivate extension", > > and it was an oversight that SE-0169 > > \<[https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>](https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md>); didn't > > include a fix here. On this \*very narrow, very specific \*access control > > issue I think it would still be worth discussing; like Xiaodi said it's not > > related to James' original thread-starter. > > > > (I maintain that the current model does \*not\* include a special case; it > > simply means the 'private' is resolved at the level of the extension rather > > than the level of its members. But that isn't what people expect and it's > > not as useful.) > > > > I agree that changing the behavior of \*all\* access modifiers on > > extensions is out of scope. (I also agree that it is a bad idea. Sorry, > > James, but wanting 'pubic' here indicates that your mental model of > > extensions does not match what Swift is actually doing, and that could get > > you into trouble.) > > > > Jordan > > > > I am not in favor of including a special case for “private extension” > > because like Jordan said, private is resolved at the level of the extension > > which is always top level currently. A change would make sense if we start > > allowing extensions that are not top level. Anything private that is top > > level is equivalent to fileprivate so why should “private extension” be any > > different? > > > > It's fair to be against this change, but I want to point out that neither > > of these are "special cases". Instead it's "access is resolved at the level > > of extension and then applied to the member" vs. "access is applied to the > > members and then resolved". > > > > Jordan > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) [Next page](https://forums.swift.org/t/idea-public-access-modifier-respected-in-type-definition/6730.md?page=2)