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.

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

Reply via email to