> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution 
> <swift-evolution@swift.org> wrote:
>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :
>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution 
>> <swift-evolution@swift.org <mailto: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.
>> -Chris
> I don’t think monitoring the usage of private vs fileprivate is fair. By 
> default, people will use private until they encounter visibility issues and 
> discover they need to change to fileprivate. So private will probably being 
> use far more than fileprivate.
> Nonetheless it does not mean people chosen private because it effectively 
> reduce the visibility to the class scope, but just because it is easier to 
> discover and to type than fileprivate and fit in many cases.
> I tend to write class will all ivars private by default (as it is a sensible 
> default), and then, when I start to write extensions and other parts, I have 
> to switch to fileprivate for a bunch of ivars. It create an inconsistent mess 
> in my ivars declaration as it is difficult to know if an ivar is private 
> because I has to be, or because I didn’t encounter a case that need it to be 
> fileprivate instead.
> Honestly, I don’t see any value in the introduction of fileprivate.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I also agree that monitoring the usage of private vs fileprivate is not fair. I 
now use private heavily simply because I don’t want the burden of mixing 
private and fileprivate (and find the name of fileprivate slightly 
verbose/ugly). But that does not mean I would vote for keeping private. I would 
still vote for going back to Swift 2 behaviour. But I agree that we can wait 
until the summer to look at this again.
swift-evolution mailing list

Reply via email to