Comments inline: > On 8 Oct 2016, at 00:56, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> I third this sentiment. fileprivate is a nice idea and very clearly has its >>> uses (which is why the proposal got traction in the first place), but when >>> combined with the other access levels, the language feature as a whole >>> feels arbitrary. In practical use, files that I felt were nicely >>> encapsulated and hiding implementation details are now a scattered mix of >>> access levels, adding cognitive load and making the code look unorganized >>> for having the gall to use extensions to split up functionality. >>> >>> Sincerely, >>> Zachary Waldowski >>> z...@waldowski.me >> >> 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.
I agree. But I think this one is different, and that's why I brought it up :) > 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. For me, this is not a question of people being unhappy. I've seen create confusion to both old and new Swift developers. > Jordan > _______________________________________________ > 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
