I'm disappointed in this turn of events. While I thought that accepting SE-0159 would have been a better outcome than rejecting it, I am certain that this is an inferior choice to both of those outcomes.
The key problem isn't principally _what_ this proposed private is. It is that, if adopted, this would be the third flavor of private in as many years. It is a new design with its own kinks (what to do about `private extension`, for example?) and the resultant churn would be most unfortunate. On Mon, Apr 3, 2017 at 14:50 David Hart via swift-evolution < swift-evolution@swift.org> 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 <cocoa...@charlessoft.com> wrote: > > On Apr 3, 2017, at 2:28 PM, David Hart via swift-evolution < > swift-evolution@swift.org> 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 > 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