> On 3 Apr 2017, at 22:01, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > 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.
I agree it is not ideal. But I’ll take it over the current status-quo where we are continually hoping between private and fileprivate without a good default. > On Mon, Apr 3, 2017 at 14:50 David Hart via swift-evolution > <swift-evolution@swift.org <mailto: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 >> <mailto:cocoa...@charlessoft.com>> wrote: >> >>> On Apr 3, 2017, at 2:28 PM, David Hart via swift-evolution >>> <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
