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