This seems like a nice compromise, though it introduces a "horizontal" issue of indentation. Not a huge issue IMHO, though I think some people may see it as a downside.
For me, it's +1, though. > On Apr 8, 2017, at 2:03 PM, Tino Heth via swift-evolution > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
