On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
<swift-evolution@swift.org> wrote:
>>> 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
> Not really. This proposal could be backed out without source-breaking changes 
> by treating private as a synonym for fileprivate and we’d have Swift 2 
> behavior without breaking source. If the core team doesn’t want to consider 
> that then we can just move on and live with it. 

Not speaking for the core team, just MHO:

I agree with Russ here, and with others who have said upthread that the “thing 
that has changed” is that we are starting to get usage experience with 
fileprivate vs private.  I think we all understand the value of having fewer 
access control levels, and so if “private” isn’t conceptually pulling its 
weight, then it is reasonable to consider phasing it out.

That said, there is no specific rush to have this discussion, and I think it is 
reasonable to put a pretty high burden of proof on someone who wants to drive 
such a proposal.  For example, if we had the discussion in the spring 
timeframe, we should have a pretty large body of Swift 3 code readily at hand 
(e.g. SwiftPM packages and other various github repos).

Given that, it should be easy enough to see how widely private is actually 
being used in practice.  If it is very rare, then the argument to ditch it 
(make it a synonym for fileprivate, and eventually phasing out fileprivate) is 
strong.  If lots of people are using private and only some are using 
fileprivate, then the discussion is quite different.


swift-evolution mailing list

Reply via email to