Exactly, this is pretty much what "protected" does - as much as there are voices against the idea to base access control based on the type, it is actually unevitable in the future IMHO anyway.
I'd personally leave the private/fileprivate access levels as they are currently and would focus the efforts on finding a nice way to express the semantics that a certain member is accessible only from within extensions or the type's subtype. > On Apr 3, 2017, at 9:50 PM, David Hart via swift-evolution > <[email protected]> wrote: > > The problem I see with that is that it would introduce orthogonal access > levels whereas they have all been hierarchal in nature up to now. > >> On 3 Apr 2017, at 21:36, Charles Srstka <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Apr 3, 2017, at 2:28 PM, David Hart via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Btw, I know what I'm going to propose is a bit crazy, but how about making >>> private visible to extensions even outside the file but in the same module? >> >> That’s actually what I suggested in my original post on the topic. My >> feeling was that it would allow breaking a particularly large type into >> separate files, thus alleviating the “huge file” problem that Swift has (and >> which Charlie Monroe brought up as a concern). >> >> It’s still what I’d prefer personally, although I can understand why the >> core team might want to restrict it to files. >> >> Charles >> > > _______________________________________________ > 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
