For those who are considering this topic, the existing document here is a good resource: https://github.com/apple/swift/blob/master/docs/AccessControl.rst Note that "class-only" and "protected" access levels are specifically called out as non-goals for Swift, with accompanying justification. Perhaps those who disagree with the design could catalog warts that would be addressed with an alternative design?
On Sat, Dec 3, 2016 at 1:46 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > An interesting format. Since it's a list, I'm not sure how to go about > commenting on the items already there with which I disagree. IMO, the > format doesn't lend itself to discussion. > > For example, _why_ do you want friend classes? By contrast, it's been said > on this list that not having them is considered a feature, and that friend > classes are a mistake. Should I just go ahead and write "not having the > ability to list specific classes and functions that can access a > property/function" as a bullet point? It seems that's not very productive. > > > On Sat, Dec 3, 2016 at 10:59 AM, Jay Abbott <j...@abbott.me.uk> wrote: > >> No idea if this will be useful, or if it will work, but I created a >> public trello board: >> >> https://trello.com/b/fmv4uV3n/swift-access-control >> >> - Pre-populated with a few of the things already mentioned. >> - There’s a link on the board to gain edit access. >> >> It’s possible this will be an utter disaster, or that nobody will use it >> at all, so go ahead and add new lists/cards with abandon. >> >> >> On Fri, 2 Dec 2016 at 22:38 Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Well, that's literally what I just mentioned above. I'd be fine with >>> getting rid of private and fileprivate. >>> On Fri, Dec 2, 2016 at 16:30 Jonathan Hull <jh...@gbis.com> wrote: >>> >>> On Dec 2, 2016, at 2:21 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> I'm not sure why that last scenario couldn't be accommodated by >>> submodules. Why wouldn't you put those two specific submodules in the same >>> parent submodule? >>> >>> >>> Why even have private and fileprivate? Why not just make everything >>> internal? Same reason… >>> >>> >>> >>> On Fri, Dec 2, 2016 at 15:35 Jonathan Hull via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> Assuming that this is true (I tend to agree), why do we need any extra >>> syntax at all? Couldn’t we just make everything accessible to extensions? >>> >>> Alternatively, if we do want to hide some things from extensions by >>> default (to prevent accidental use), I had a proposal a while back which >>> had a very simple way to control what is shared. Basically, you could have >>> a special import statement which allows you to extend knowledge/access of >>> the hidden parts to another file (you were also able to limit the range of >>> this ability if needed). >>> >>> Most of the feedback at the time seemed to want submodules instead, but >>> I still think there will still eventually be a need for something like >>> this. As others have mentioned, the current system is inflexible >>> (especially to the common use cases), causing people to keep requesting >>> additions… and forcing them to give wider access than they want to in the >>> mean time. Even if we have sub-modules, someone will want to share with a >>> specific other sub-module, but not make things public. >>> >>> >>> >>> On Dec 1, 2016, at 1:31 AM, Tino Heth via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> >>> It also means that anybody who want to access your private var will just >>> have to write an extension to expose it. >>> >>> imho this is wrong thinking: >>> Access control is no tool to offer real "protection" — it can't stop >>> someone who wants to break a system. >>> Especially in the world of open source, it is merely an advice from the >>> author not to do certain things. >>> _______________________________________________ >>> 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 >>> >>> _______________________________________________ >>> 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