> On Jan 26, 2017, at 10:21 AM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jan 25, 2017, at 10:40 AM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> This is contrary to several deliberate design decisions, if I understand >> correctly. >> >> First, revisions to visibility rules in the Swift 3 timeline were made with >> the deliberate intention that it should be possible to model greater >> visibility within a type (e.g. public members) without actually exporting >> that type. As Swift does not have optional warnings that can be turned off, >> it would be incongruous if the language also warned users away from creating >> internal types or variables before they are used. Unlike warnings about >> unused variables within a scope, which are by definition local, a warning >> such as proposed would be much more disruptive. >> >> Second, a variable with no access modifier defaults to internal, and this is >> deliberate for the purpose of progressive disclosure (i.e. it is, by design, >> possible for a new user to write useful code separated across multiple files >> without learning what access modifiers are). This would be undone if nearly >> every such use prompted a warning. >> >> In summary, I think the issue here is more one of style than safety, and IMO >> is more within the scope of a linter. > > One place a warning like this would be useful is with private/fileprivate > code that resulted from migrating Swift 2 to 3. Xcode's automatic migrator > naively changed all Swift 2 private declarations to fileprivate, since that's > the obvious semantics-preserving change, but it's possible that this has had > the knock-on effect that people overuse "fileprivate" because that's the > example set by the migrator, and not for technical reasons. Given the number > of ideas that have been raised about further extending or tweaking the > visibility model since Swift 3, it's clear there's still some dissatisfaction > with our current model, and we've been trying to get clear information about > how well the existing model is working. Fileprivate is potentially > overrepresented in code in the wild due to the migrator's behavior and people > cargo-culting the migrator's code patterns, so a warning that suggested to > users when they could make use of 'private' might help steer people to clean > up their migrated code and give us a better idea of how well the model fits > real-world problems.
I disagree that this is appropriate. If there was a warning for use of fileprivate when private would be sufficient, there would have to be a way for a developer to indicate “no, my eventual *intent* is for this to be used by other code within this file”. Otherwise, 1. people may have to go a long period with spurious warnings in their database, or 2. to make it private with a comment “this can actually be fileprivate if you need to access it”, or 3. make it private and hope the next developer working on the code can evaluate that this value is ok to be fileprivate private provides minimal safety to the code as a developer editing a file can just change the variable to fileprivate to accomplish what they need. Private provides an indication of intent - that this code was not intended to allow direct, external manipulation. Perhaps there should have been a ‘maybeprivate’ keyword for migration? :-) -DW _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
