Responding on the pro side, but I don't endorse this proposal without more details:
~Robert Widmann 2017/01/25 13:40、Xiaodi Wu <xiaodi...@gmail.com> のメッセージ: > 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. That decision wasn't really one made to support a deliberate design, but to help make migration of fileprivate easier IIRC (Jordan Rose probably remembers better than I do of the conversation we had about this). It's important to note we already provide module-wide warnings (namely if we detect you mutating a let-bound member we offer a fixit at the site of the member decl) so this isn't new. > > 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. That enforces hiding from clients, OP wants to enforce a model where we enforce data hiding from yourself as well. If a variable's access needs to be escalated we can provide that fixit as well (instead of the current errors we offer now which are usually spurious type errors because lookup barfs). > > In summary, I think the issue here is more one of style than safety, and IMO > is more within the scope of a linter. > >> On Wed, Jan 25, 2017 at 12:27 Robert Widmann via swift-evolution >> <swift-evolution@swift.org> wrote: >> So, to be clear, a warning about making internal variables more private >> based on their usage in the entire module? >> >> Sounds doable. Probably wouldn't need to go through evolution to get it too >> (but I'll let others make that call). Please file an SR about this too. >> >> ~Robert Widmann >> >> 2017/01/25 3:25、Dave Kliman via swift-evolution <swift-evolution@swift.org> >> のメッセージ: >> >>> Hi! >>> >>> I’m somewhat new to swift, so this issue may have been covered. >>> >>> I really like how I get a warning for variables I’ve declared, but have not >>> mutated, or constants that I did not read. >>> >>> What about warnings for anything not accessed outside its declared scope, >>> encouraging the use of private, or fileprivate more often? >>> >>> -Dave >>> _______________________________________________ >>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
