I think that is why he is saying (and I agree), that ‘fileprivate’ needs to be the soft-default. That way private will mean something.
His point that this gets rid of the primary use-case of ‘private’ (over ‘fileprivate’) is also extremely relevant. > On Apr 7, 2017, at 4:51 AM, Gwendal Roué via swift-evolution > <swift-evolution@swift.org> wrote: > > >> Le 7 avr. 2017 à 13:44, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> No. I believe it makes the language worse, not better. It doesn’t address >> the real problems with access control. The largest problem is the inability >> to form scopes between files and the entire module. The problem with >> `fileprivate` and `private` is a naming problem, not a semantics problem. > > This is the base of your argument, and I think it is wrong, considering that > code is a living matter, not a static one. > > Too many properties initially declared as `private` have to be declared > `fileprivate` later, because the code is evolving. And this change is usually > performed just to tame a compiler error. > > This is why the current private/fileprivate situation is actually a semantics > problem. Private is not stable enough to mean anything. > > Gwendal Roué > > _______________________________________________ > 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