[swift-evolution] private & fileprivate

[David Waite]

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 at swift.org> wrote:
>> On Oct 7, 2016, at 3:56 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Oct 7, 2016, at 15:15, William Sumner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> On Oct 7, 2016, at 3:05 PM, Zach Waldowski via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161010/b0760fa7/attachment.html>