[swift-evolution] Enhancing access levels without breaking changes

Jonathan Hull jhull at gbis.com
Sun Apr 9 21:14:34 CDT 2017

This struck me as a bit odd at first, but the more I think about it, the more I really like the ability to nest extensions/scopes.  The one issue I see is sticking that public extension inside a private one.  I think you would have to mark ‘secret: Int’ as private instead of the extension itself to allow the effect you are looking for...

What I ultimately want is the ability to declare storage in extensions in the same submodule. Combining that with fileprivate will allow the same tricks without the indentation (together in their own file).  This nesting will help in the mean-time (and would still be useful after for those who prefer to organize their code in fewer/longer files).  I think it could be helpful in other ways too...


> On Apr 8, 2017, at 5:03 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> Imho there is a simple solution to reach the goals of SE-0169 without breaking compatibility:
> Just allow extensions inside type declarations.
> class MyVC: UIViewController {
>     private let numberOfSections = 0
>     extension: UITableViewDataSource {
>         // Skipping the class and assume we want to extend the surrounding type
>         func numberOfSections(in tableView: UITableView) -> Int {
>             return numberOfSections
>         }
>         func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
>             return 0
>         }
>     }
>     private extension {
>         // this would contain everything that shoudn't be visible for other extensios
>         var secret: Int = 0
>         public extension MyFriendClass {
>             // oh, well, I make an exception here for a trustworthy type
>             func checkSecret(of controller: MyVC) -> Bool {
>                 return controller.secret > 0
>             }
>         }
>         private extension {
>             // this is so secret, I'm not even allowed to copy it
>         }
>     }
>     public func myMethod() {
>         print("This is just a boring method")
>     }
> }
> It has the downside of shifting code to the right (you could as well leave those extension-blocks unindented), but lots of advantages:
> - No change for private needed
> - It can be nested as much as you like to satisfy even the most absurd desires of encapsulation
> - It reminds me on operator definitions inside type declarations 
> - No change for fileprivate needed (but actually, I think there is very little need to keep fileprivate)
> I wish this would only be a joke, but writing the example, I actually started liking the concept (but I have a terrible headache right now which might affect my mind) — so either this receives some feedback, or I might start re-proposing this ;-)
> - Tino
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170409/02d2b69b/attachment.html>

More information about the swift-evolution mailing list