That's definitely a legit use case. I think it's different from the
overarching proposal in that: 1) it has no progressive disclosure
implications because it is about one explicitly chosen level vs another;
and 2) it is about reducing uses that were clearly called out as suboptimal
in an approved proposal. IMO, it would be consistent to implement this
particular warning without anything else.
···
On Thu, Jan 26, 2017 at 11:21 Joe Groff <jgroff@apple.com> 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.-Joe