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 <[email protected]> wrote:
> On Dec 2, 2016, at 2:21 PM, Xiaodi Wu <[email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > 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
