Re: [swift-evolution] warnings for out of scope?

[Michael Ilseman via swift-evolution]

This seems best handled as a lint rule, probably filed under “pedantic”. It 
makes sense to apply to a project at certain milestones, but could be noisy 
during incremental development.

> On Jan 25, 2017, at 12:25 AM, Dave Kliman via swift-evolution 
>  wrote:
> 
> 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

Re: [swift-evolution] warnings for out of scope?

[David Waite via swift-evolution]

> On Jan 26, 2017, at 10:21 AM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Jan 25, 2017, at 10:40 AM, Xiaodi Wu via swift-evolution 
>>  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

Re: [swift-evolution] warnings for out of scope?

[Xiaodi Wu via swift-evolution]

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  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] warnings for out of scope?

[Joe Groff via swift-evolution]

> On Jan 25, 2017, at 10:40 AM, Xiaodi Wu via swift-evolution 
>  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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] warnings for out of scope?

[Xiaodi Wu via swift-evolution]

On Wed, Jan 25, 2017 at 4:34 PM, Robert Widmann 
wrote:

> Responding on the pro side, but I don't endorse this proposal without more
> details:
>
> ~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).
>

Sure, the motivation is not ambiguous.

In the past, when new syntax for yet another access level has been
proposed, I've argued that perfect data hiding from yourself (as opposed to
clients) has been a non-goal (given the access levels available today) and
probably should continue to be. There's been disagreement about that--fine.

But _enforcing_ data hiding from yourself as The One True Way of Swift is
something else. Though not technically *source* breaking for existing code,
it is certainly radically design breaking. Far from being a bugfix, I'd
argue that such a change is big enough to merit one of those
manifesto-style big-picture discussions, and I'd want to be convinced of
huge wins for such a U-turn in direction.


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

Re: [swift-evolution] warnings for out of scope?

[Jordan Rose via swift-evolution]

> On Jan 25, 2017, at 14:34, Robert Widmann via swift-evolution 
>  wrote:
> 
> Responding on the pro side, but I don't endorse this proposal without more 
> details:
> 
> ~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).

Saying it's about "migration" is disingenuous. The particular language in 
SE-0025 

 reads:

• The compiler should not warn when a broader level of access control 
is used within a type with more restrictive access, such as internal within a 
private type. This allows the designer of the type to select the access they 
would use were they to make the type more widely accessible. (The members still 
cannot be accessed outside the enclosing lexical scope because the type itself 
is still restricted, i.e. outside code will never encounter a value of that 
type.)

That is, this was a change made to support local design that happened to 
simplify the rules around access, particularly

• The default level of access control anywhere is internal.

So it still qualifies as "deliberate design".

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] warnings for out of scope?

[Robert Widmann via swift-evolution]

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

~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@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

Re: [swift-evolution] warnings for out of scope?

[Xiaodi Wu via swift-evolution]

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 
> のメッセージ:
>
> 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

Re: [swift-evolution] warnings for out of scope?

[Robert Widmann via swift-evolution]

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@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] warnings for out of scope?

[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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution