Responding on the pro side, but I don't endorse this proposal without more 

~Robert Widmann

2017/01/25 13:40、Xiaodi Wu <> のメッセージ:

> 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 
>> <> 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 <> 
>> のメッセージ:
>>> 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 mailing list
swift-evolution mailing list

Reply via email to