Unfortunately, my agreement may come off a bit backhanded. IMHO, the “fileprivate” problem is due to SE-0025 trying to add sophistication to access control too fast.
My observation is that Swift developers as a whole really have not yet come to a conclusion that the permissions already present in the language were truly insufficient for large scale software development. More so, *how* they are insufficient wasn’t clearly represented - for instance, I’ve heard complaints that files become too large by having to bundle dependent extensions and classes, but SE-0025 did little to target their desire for a more manageable codebase. Instead, it allows them to make sections of those large files “more private”. I’m convinced as the Swift language and other Swift-based projects both gain more maturity, we will be able to get a holistic view of how access control should work and how it should correlate to project structure. Before then, any change may simply do more harm than good. -DW > On Oct 10, 2016, at 10:59 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: >> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> Beyond the textual change of using a different modifier name, I don’t see >>> how the encapsulation and organization of code could be affected. Really, >>> there’s not much point in rehashing prior discussion of SE-0025 unless >>> there’s a previously unconsidered angle. >> >> I strongly agree with this sentiment. SE-0025 was very heavily discussed, >> and while many people were not satisfied with the solution we went with >> (including me!), it was what the core team and community converged on. I >> don't expect us to change access control again until and unless we decide to >> change the model in some way, and even then I think we'll want to go through >> extra effort to maintain compatibility with Swift 3. As has been mentioned >> repeatedly, the bar for source-breaking changes is much higher than it was >> in the first few months of swift-evolution. >> >> I actually consider it very lucky that most of our changes so far have been >> fairly non-controversial. Everybody has a different idea of what would make >> Swift a better language, and all of us well-meaning. But when those ideas >> conflict, some group is going to end up unhappy. I'm actually very glad that >> (a) we haven't had too many of these cases, and (b) even when we have, >> people have been able to accept it and move on to contributing to the next >> issue. > > > Strong agreement here as well. This proposal has been litigated numerous > times already, and the bar for source-breaking changes is much higher now. To > effectively re-open the discussion would require a proposal that significant > changes the model with a lot of evidence that such a new model is a drastic > improvement over what we have now. “Back out SE-0025” is not a viable option > now. > > - Doug > > _______________________________________________ > 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
