> On Apr 7, 2017, at 8:37 AM, Jonathan Hull via swift-evolution > <[email protected]> wrote: > 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.
Keywords aren't completely arbitrary. Programmers will always reach for 'private' first, both from familiarity with other languages and because of the obvious contrast with 'public'. You can teach them not to do that, but that then becomes something they have to specifically learn instead of something that comes intuitively. > His point that this gets rid of the primary use-case of ‘private’ (over > ‘fileprivate’) is also extremely relevant. That depends very much on what you put in a single file. If you generally just put a single type and its extensions in a file, then yes, 'private' and 'fileprivate' are essentially the same, other than for nested types. If you put other code in the same file, 'private' remains meaningfully stronger than 'fileprivate'. In both cases, 'private' is reinforced as a default choice; but you do lose that ability to prevent extensions from directly accessing the stored properties of a type, which I agree is a significant loss. John. > > >> On Apr 7, 2017, at 4:51 AM, Gwendal Roué via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> Le 7 avr. 2017 à 13:44, Matthew Johnson via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
