> 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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
