> On 13 Oct 2016, at 08:25, Jean-Daniel via swift-evolution
> <[email protected]> wrote:
>
>
>> Le 13 oct. 2016 à 07:52, Chris Lattner via swift-evolution
>> <[email protected] <mailto:[email protected]>> a écrit :
>>
>> On Oct 12, 2016, at 9:56 PM, Russ Bishop via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
> [email protected]
> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
