Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Vladimir.S via swift-evolution]

It’s not
difficult for me I guess.
>
> Right. I do that myself more than I would like to admit.
> But when we only loosen up/tighten down during coding then access
> levels are almost useless.
> The point of access level control is in the design, not in the
coding.
> If we made a design (including access levels) and then have to
dial
> back, that should be a warning that something is wrong.
> To me, this is an argument in favour of the proposal.
>
> Rien.
>
>
>
> >   As such, I don’t believe that this change was “Actively
Harmful”,
> especially for new developers who have a clean slate or simply are
> leaving everything unmarked (internal) anyhow until they move
up to
> more advanced topics.  Unraveling a generic or functional code
someone
> else wrote uses way more cognitive power.
> >
> > I’d like to address the suggestion that the migration for
SE-0159
> could “simply” be a search and replace without loss of
functionality.
> This doesn’t make sense if you consider the entire code lifecycle.
> Sure the code gets migrated and compiles.  This is fine if they
code
> _never_ has to be read again.  But as we know, code is written
once and
> _read many times_ as it will need to be maintained.  The
distinction
> between private and fileprivate contains information, and
although it
> may work correctly now, some information meant to help maintain
that
> code has been lost if these keywords are merged and the
functionality
> of scoped access is removed.  So yes if you don’t maintain the
code
> where this migration takes place, this would be ok. But Swift
strives
> for readability.  Moving classes to separate files to address
these
> issues, creates a multitude of Bunny classes where again for
> readability some classes belong together in the same file for
ease of
> comprehension (again, code is written once , read many times)
> >
> > * Does this proposal fit well with the feel and direction of
Swift?
> > The spirit of the proposal to simplify access levels is well
taken.
> This proposal however simplifies at the expense of lost
functionality
> (Scoped Access levels) with no replacement.  The threads talk a
about
> submodules and other solutions that could fill this gap that are
not on
> the roadmap, planned or possible which makes them
non-admissible in
> considering this proposal.
> >
> > * If you have used other languages, libraries, or package
managers
> with a similar feature, how do you feel that this proposal
compares to
> those?
> > I am more familiar with scoped access so perhaps that feels more
> natural to me.  But with the current implementation Swift users
can
> choose whether they use File Based or Scope Based tools, so
although
> not ideal to either side, acceptable until a suitable replacement
could
> be forged.
> >
> > * How much effort did you put into your review? A glance, a
quick
> reading, or an in-depth study?
    >     > Re-read SE-0025/proposal/most of this very long thread
> >
> >
> >
> >
> > From: <swift-evolution-boun...@swift.org
<mailto:swift-evolution-boun...@swift.org>
> <mailto:swift-evolution-boun...@swift.org
<mailto:swift-evolution-boun...@swift.org>>> on behalf of Tino Heth via
> swift-evolution <swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
> <mailto:swift-evolution@swift.org
<mailto:swift-evolution@swift.org>>>
> > Reply-To: Tino Heth <2...@gmx.de <mailto:2...@gmx.de>
<mailto:2...@gmx.de <mailto:2...@gmx.de>>>
> > Date: Monday, March 27, 2017 at 6:48 AM
> > To: Zach Waldowski <z...@waldowski.me
<mailto:z...@waldowski.me> <mailto:z...@waldowski.me
<mailto:z...@waldowski.me>>>
> > Cc: <swift-evolution@swift.org
<mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org
<mailto:swift-evolution@swift.org>>>
> > Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private
Access
> Levels
> >
> >
> >
> >> I am now absolutely thrilled to create a filter to Mark As Read
> anything else arising from this thread. Good 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Vladimir.S via swift-evolution]

he design, not in the
coding.
> If we made a design (including access levels) and then have to dial
> back, that should be a warning that something is wrong.
> To me, this is an argument in favour of the proposal.
>
> Rien.
>
>
>
> >   As such, I don’t believe that this change was “Actively Harmful”,
> especially for new developers who have a clean slate or simply are
> leaving everything unmarked (internal) anyhow until they move up to
> more advanced topics.  Unraveling a generic or functional code
someone
> else wrote uses way more cognitive power.
> >
> > I’d like to address the suggestion that the migration for SE-0159
> could “simply” be a search and replace without loss of functionality.
> This doesn’t make sense if you consider the entire code lifecycle.
> Sure the code gets migrated and compiles.  This is fine if they code
> _never_ has to be read again.  But as we know, code is written
once and
> _read many times_ as it will need to be maintained.  The distinction
> between private and fileprivate contains information, and although it
> may work correctly now, some information meant to help maintain that
> code has been lost if these keywords are merged and the functionality
> of scoped access is removed.  So yes if you don’t maintain the code
> where this migration takes place, this would be ok. But Swift strives
> for readability.  Moving classes to separate files to address these
> issues, creates a multitude of Bunny classes where again for
> readability some classes belong together in the same file for ease of
> comprehension (again, code is written once , read many times)
> >
> > * Does this proposal fit well with the feel and direction of Swift?
> > The spirit of the proposal to simplify access levels is well taken.
> This proposal however simplifies at the expense of lost functionality
> (Scoped Access levels) with no replacement.  The threads talk a about
> submodules and other solutions that could fill this gap that are
not on
> the roadmap, planned or possible which makes them  non-admissible in
> considering this proposal.
> >
> > * If you have used other languages, libraries, or package managers
> with a similar feature, how do you feel that this proposal
compares to
> those?
> > I am more familiar with scoped access so perhaps that feels more
> natural to me.  But with the current implementation Swift users can
> choose whether they use File Based or Scope Based tools, so although
> not ideal to either side, acceptable until a suitable replacement
could
> be forged.
> >
> > * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
    >     > Re-read SE-0025/proposal/most of this very long thread
> >
> >
> >
> >
> > From: <swift-evolution-boun...@swift.org
<mailto:swift-evolution-boun...@swift.org>
> <mailto:swift-evolution-boun...@swift.org
<mailto:swift-evolution-boun...@swift.org>>> on behalf of Tino Heth via
> swift-evolution <swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
> <mailto:swift-evolution@swift.org
<mailto:swift-evolution@swift.org>>>
> > Reply-To: Tino Heth <2...@gmx.de <mailto:2...@gmx.de>
<mailto:2...@gmx.de <mailto:2...@gmx.de>>>
> > Date: Monday, March 27, 2017 at 6:48 AM
> > To: Zach Waldowski <z...@waldowski.me
<mailto:z...@waldowski.me> <mailto:z...@waldowski.me
<mailto:z...@waldowski.me>>>
> > Cc: <swift-evolution@swift.org
<mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org
<mailto:swift-evolution@swift.org>>>
> > Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access
> Levels
> >
> >
> >
> >> I am now absolutely thrilled to create a filter to Mark As Read
> anything else arising from this thread. Good luck.
> >
> > That might be a good idea — after more than 200 messages, and a
quite
> circular discussion with an unhealthy amount of ignorance for the
> opposing side ;-).
> >
> > To fight the latter, I just tried to t

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

ped) details, that should not be exposed to whole file level.
>* with proposed solution it is clear that any memeber declared in
> extension block is a native part of type. We see all members in the same
> type declaration.
>* proposed solution has a simple mental model - "all that is defined
> inside type declaration is naturally a part of that type, 'scoped' access
> 'uses' same rules as usually".
>
> Vladimir.
>
> >
> > Ross
> >
> >
> > On Mon, Mar 27, 2017 at 4:26 PM, Rien via swift-evolution
> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> >
> > > On 27 Mar 2017, at 16:46, Steven Knodl via swift-evolution <
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> > >
> > > Late to the party here
> > >
> > > * What is your evaluation of the proposal?
> > > I’m -1 on this.  The proposal is not a difficult read, but may
> have been simply more simply named “Remove Scoped Access Level/Revert
> SE-0025” as that is what is being proposed. “Fix” seems to me to be a
> unfortunately worded judgmental proposal title.
> > >
> > > * Is the problem being addressed significant enough to warrant a
> change?
> > > No.  I consider myself to be a fairly “new/n00b” Obj-C/Swift
> developer. Although SE-0025 was a change that required source changes when
> implemented, the reasoning was not difficult to understand and changes were
> simple to make once identified.   Here they are from SE-0025
> > >
> > >   • public: symbol visible outside the current module
> > >   • internal: symbol visible within the current module
> > >   • fileprivate: symbol visible within the current file
> > >   • private: symbol visible within the current declaration
> > >
> > > Moving forward these changes are not difficult to comprehend.  I
> tend to make _everything_ “private” up front so I don’t have any API
> leakage.  Then dial back to “fileprivate” as needed.  It’s not difficult
> for me I guess.
> >
> > Right. I do that myself more than I would like to admit.
> > But when we only loosen up/tighten down during coding then access
> > levels are almost useless.
> > The point of access level control is in the design, not in the
> coding.
> > If we made a design (including access levels) and then have to dial
> > back, that should be a warning that something is wrong.
> > To me, this is an argument in favour of the proposal.
> >
> > Rien.
> >
> >
> >
> > >   As such, I don’t believe that this change was “Actively Harmful”,
> > especially for new developers who have a clean slate or simply are
> > leaving everything unmarked (internal) anyhow until they move up to
> > more advanced topics.  Unraveling a generic or functional code
> someone
> > else wrote uses way more cognitive power.
> > >
> > > I’d like to address the suggestion that the migration for SE-0159
> > could “simply” be a search and replace without loss of functionality.
> > This doesn’t make sense if you consider the entire code lifecycle.
> > Sure the code gets migrated and compiles.  This is fine if they code
> > _never_ has to be read again.  But as we know, code is written once
> and
> > _read many times_ as it will need to be maintained.  The distinction
> > between private and fileprivate contains information, and although it
> > may work correctly now, some information meant to help maintain that
> > code has been lost if these keywords are merged and the functionality
> > of scoped access is removed.  So yes if you don’t maintain the code
> > where this migration takes place, this would be ok. But Swift strives
> > for readability.  Moving classes to separate files to address these
> > issues, creates a multitude of Bunny classes where again for
> > readability some classes belong together in the same file for ease of
> > comprehension (again, code is written once , read many times)
> > >
> > > * Does this proposal fit well with the feel and direction of Swift?
> > > The spirit of the proposal to simplify access levels is well taken.
> > This proposal however simplifies at the expense of lost functionality
> > (Scoped Access levels) with no replacement.  The threads talk a about
> > submodules and other solutions that could fill this gap that are not
> on
> >   

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Vladimir.S via swift-evolution]

ls) with no replacement.  The threads talk a about
submodules and other solutions that could fill this gap that are not on
the roadmap, planned or possible which makes them  non-admissible in
considering this proposal.
>
> * If you have used other languages, libraries, or package managers
with a similar feature, how do you feel that this proposal compares to
those?
> I am more familiar with scoped access so perhaps that feels more
natural to me.  But with the current implementation Swift users can
choose whether they use File Based or Scope Based tools, so although
not ideal to either side, acceptable until a suitable replacement could
be forged.
>
> * How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
> Re-read SE-0025/proposal/most of this very long thread
>
>
>
>
> From: <swift-evolution-boun...@swift.org
<mailto:swift-evolution-boun...@swift.org>> on behalf of Tino Heth via
swift-evolution <swift-evolution@swift.org
<mailto:swift-evolution@swift.org>>
> Reply-To: Tino Heth <2...@gmx.de <mailto:2...@gmx.de>>
> Date: Monday, March 27, 2017 at 6:48 AM
> To: Zach Waldowski <z...@waldowski.me <mailto:z...@waldowski.me>>
> Cc: <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access
Levels
>
>
>
>> I am now absolutely thrilled to create a filter to Mark As Read
anything else arising from this thread. Good luck.
>
> That might be a good idea — after more than 200 messages, and a quite
circular discussion with an unhealthy amount of ignorance for the
opposing side ;-).
>
> To fight the latter, I just tried to take the position that "new
private" is really important, and this imho leads to interesting
consequences...
> This access modifier really doesn't solve a problem, like "let" does
(unless the problem you want to solve is having a language with private
access).
> Have a look at this:
>
> public struct SeperateConcerns {
>private var foo: Int = 0
>public mutating func updateFoo(_ value: Int) {
>   print("The only allowed way to change foo was invoked")
>   foo = value
>}
>
>private var bar: Int = 0
>public mutating func updateBar(_ value: Int) {
>   print("The only allowed way to change bar was invoked")
>   bar = value
>}
>
>private var foobar: Int = 0
>public mutating func updateFoobar(_ value: Int) {
>   print("The only allowed way to change foobar was invoked")
>   foobar = value
>}
> }
>
>
> You can protect foo from being changed by code in other files, and
from extensions in the same file — and if the latter is a concern,
there should also be a way to limit access to foo to specific function
in scope.
> Afaik, somebody proposed "partial" type declarations, but without
them, the meaning of private is rather arbitrary, and the feature is
only useful for a tiny special case.
> If we had partial types, the situation would be different, and if
would be possible to declare extensions inside a partial declaration of
another type, we could even remove fileprivate without an replacement
(I guess I should write a separate mail for this thought…)
> ___ swift-evolution
mailing list swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>

___
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
<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] [Review] SE-0159: Fix Private Access Levels

[Nevin Brackett-Rozinsky via swift-evolution]

On Mon, Mar 27, 2017 at 1:47 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 27, 2017, at 12:00 PM, Ross O'Brien via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 
>
>
> Creates a mechanism that actually makes sense for what people are using
> ‘extension’ for, solves the scoping problems, eliminates the need for
> fileprivate, solves all the problems that people are complaining about.
>

No it does not.

In addition to the protocol-conformance pattern that Ross describes, people
also use extensions to let types declared elsewhere (even in another
module!) work with types declared locally. So in Foo.swift we will have the
implementation of Foo, as well as things like “extension String { /*
Foo-related stuff */ }”.

The file-scope access level, which had been and should be spelled
“private”, enables those extensions of external types to access
implementation details of Foo to do their work. Thus Ross’s scheme does not
eliminate the need for file-level visibility at all. In my view, what we
really need is an access level *broader* than a single file, so that
implementation details can be made visible across a select group of
tightly-related files but not the rest of the module. However that is out
of scope for Swift 4.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 27, 2017, at 12:00 PM, Ross O'Brien via swift-evolution 
>  wrote:
> 
> I'm considering this from a different angle.
> 
> When we declare a type, we declare properties and functions which that type 
> has.
> When we extend a type, we add functions to the type. (I'm including computed 
> properties in this.)
> It's become an idiom of Swift to declare an extension to a type for each 
> protocol we want it to conform to, for reasons of code organisation and 
> readability. This may be true even if conformance to the protocol was a 
> primary intent of creating the type in the first place.
> 
> The intent of the scoped access level is to allow programmers to create 
> properties and functions which are limited to the scope of their declaration. 
> A protocol conformance can be written, with the aid of helper functions, in 
> the confidence that the helper functions are not visible outside the 
> extension, minimising their impact on other components of the module.
> However, some protocol conformances require the type to have a specific 
> property, which the extension cannot facilitate. Some protocol conformances 
> don't require a property, but it would be really useful to have one, and 
> again an extension can't facilitate.
> 
> Example: we want to be able to write this, but we can't:
> private protocol Bar
> {
>   var integer : Int { get }
>   func increment()
> }
> 
> struct Foo
> {
> }
> 
> extension Foo : Bar
> {
>   var integer : Int
> 
>   private var counter : Int
>   func increment()
>   {
> counter += 1
>   }
> }
> 
> This leads to a workaround: that properties are added to the original type, 
> and declared as fileprivate. They're not intended to be visible to any scope 
> other than the conforming extension - not even, really, to the type's 
> original scope.
> 
> Continuing the example: we've compromised and written this:
> private protocol Bar
> {
>   var integer : Int { get }
>   func increment()
> }
> 
> struct Foo
> {
>   fileprivate var integer : Int
>   fileprivate var counter : Int
> }
> 
> extension Foo : Bar
> {
>   func increment()
>   {
> counter += 1
>   }
> }
> 
> This is not a fault of fileprivate (though it's a clunky name), or private. 
> Renaming these levels does not solve the problem. Removing private, such that 
> everything becomes fileprivate, does not solve the problem. The problem is in 
> the extension system.
> (At this point I realise I'm focusing on one problem as if it's the only one.)
> 
> Supposing we approached extensions differently. I think around SE-0025 we 
> were considering a 'nested' access level.
> 
> Supposing we created a 'conformance region' inside a type declaration - a 
> scope nested within the type declaration scope - and that this conformance 
> region had its own access level. It's inside the type declaration, not 
> separate from it like an extension, so we can declare properties inside it. 
> But literally the only properties and functions declared inside the region 
> but visible anywhere outside of it, would be properties and functions 
> declared in the named protocol being conformed to.
> 
> So, visually it might look like this:
> 
> private protocol Bar
> {
>   var integer : Int { get }
>   func increment()
> }
> 
> struct Foo
> {
>   conformance Bar // or conformance Foo : Bar, but since the region is inside 
> Foo that's redundant
>   {
> var integer : Int // visible because Foo : Bar, at Bar's access level
> 
> var counter : Int = 0 // only visible inside the conformance scope, 
> because not declared in Bar
> 
> func increment() // visible because Foo : Bar, at Bar's access level
> {
>   counter += 1
> }
>   }
> }
> 
> I've introduced a new keyword, conformance, though it may be clear enough to 
> keep using extension inside a scope for this. Foo still conforms to Bar, in 
> the same file. We've removed 'extension Foo :' and moved a '}' for this, but 
> that's not a breaking change as this is an addition. Readability is 
> compromised to the extent that this conformance is indented one level.
> 
> I've not long had the idea. It's a different approach and may be worth a 
> discussion thread of its own for - or someone might point out some glaringly 
> obvious flaw in it. If it's useful, I don't know the full implications this 
> would have, such as how much this would reduce the use of fileprivate (e.g. 
> to none, to the minimal levels expected in SE-0025, or no effect at all). 
> It's just intended to remove a problem which fileprivate is applied as a bad 
> workaround for.

+1. Creates a mechanism that actually makes sense for what people are using 
‘extension’ for, solves the scoping problems, eliminates the need for 
fileprivate, solves all the problems that people are complaining about.

You could also enforce it by disallowing a ‘conformance’ block from containing 
any non-private methods that don’t work towards implementing the protocol.

Charles

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Ross O'Brien via swift-evolution]

n00b” Obj-C/Swift developer.
> Although SE-0025 was a change that required source changes when
> implemented, the reasoning was not difficult to understand and changes were
> simple to make once identified.   Here they are from SE-0025
> >
> >   • public: symbol visible outside the current module
> >   • internal: symbol visible within the current module
> >   • fileprivate: symbol visible within the current file
> >   • private: symbol visible within the current declaration
> >
> > Moving forward these changes are not difficult to comprehend.  I tend to
> make _everything_ “private” up front so I don’t have any API leakage.  Then
> dial back to “fileprivate” as needed.  It’s not difficult for me I guess.
>
> Right. I do that myself more than I would like to admit.
> But when we only loosen up/tighten down during coding then access levels
> are almost useless.
> The point of access level control is in the design, not in the coding.
> If we made a design (including access levels) and then have to dial back,
> that should be a warning that something is wrong.
> To me, this is an argument in favour of the proposal.
>
> Rien.
>
>
>
> >   As such, I don’t believe that this change was “Actively Harmful”,
> especially for new developers who have a clean slate or simply are leaving
> everything unmarked (internal) anyhow until they move up to more advanced
> topics.  Unraveling a generic or functional code someone else wrote uses
> way more cognitive power.
> >
> > I’d like to address the suggestion that the migration for SE-0159 could
> “simply” be a search and replace without loss of functionality.  This
> doesn’t make sense if you consider the entire code lifecycle.  Sure the
> code gets migrated and compiles.  This is fine if they code _never_ has to
> be read again.  But as we know, code is written once and _read many times_
> as it will need to be maintained.  The distinction between private and
> fileprivate contains information, and although it may work correctly now,
> some information meant to help maintain that code has been lost if these
> keywords are merged and the functionality of scoped access is removed.  So
> yes if you don’t maintain the code where this migration takes place, this
> would be ok. But Swift strives for readability.  Moving classes to separate
> files to address these issues, creates a multitude of Bunny classes where
> again for readability some classes belong together in the same file for
> ease of comprehension (again, code is written once , read many times)
> >
> > * Does this proposal fit well with the feel and direction of Swift?
> > The spirit of the proposal to simplify access levels is well taken.
> This proposal however simplifies at the expense of lost functionality
> (Scoped Access levels) with no replacement.  The threads talk a about
> submodules and other solutions that could fill this gap that are not on the
> roadmap, planned or possible which makes them  non-admissible in
> considering this proposal.
> >
> > * If you have used other languages, libraries, or package managers with
> a similar feature, how do you feel that this proposal compares to those?
> > I am more familiar with scoped access so perhaps that feels more natural
> to me.  But with the current implementation Swift users can choose whether
> they use File Based or Scope Based tools, so although not ideal to either
> side, acceptable until a suitable replacement could be forged.
> >
> > * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
> > Re-read SE-0025/proposal/most of this very long thread
> >
> >
> >
> >
> > From: <swift-evolution-boun...@swift.org> on behalf of Tino Heth via
> swift-evolution <swift-evolution@swift.org>
> > Reply-To: Tino Heth <2...@gmx.de>
> > Date: Monday, March 27, 2017 at 6:48 AM
> > To: Zach Waldowski <z...@waldowski.me>
> > Cc: <swift-evolution@swift.org>
> > Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access
> Levels
> >
> >
> >
> >> I am now absolutely thrilled to create a filter to Mark As Read
> anything else arising from this thread. Good luck.
> >
> > That might be a good idea — after more than 200 messages, and a quite
> circular discussion with an unhealthy amount of ignorance for the opposing
> side ;-).
> >
> > To fight the latter, I just tried to take the position that "new
> private" is really important, and this imho leads to interesting
> consequences...
> > This access modifier really doesn't solve a problem, like "let" does
> (unless 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 27 Mar 2017, at 16:46, Steven Knodl via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Late to the party here 
>  
> * What is your evaluation of the proposal?
> I’m -1 on this.  The proposal is not a difficult read, but may have been 
> simply more simply named “Remove Scoped Access Level/Revert SE-0025” as that 
> is what is being proposed. “Fix” seems to me to be a unfortunately worded 
> judgmental proposal title.
>  
> * Is the problem being addressed significant enough to warrant a change?
> No.  I consider myself to be a fairly “new/n00b” Obj-C/Swift developer. 
> Although SE-0025 was a change that required source changes when implemented, 
> the reasoning was not difficult to understand and changes were simple to make 
> once identified.   Here they are from SE-0025
>  
>   • public: symbol visible outside the current module
>   • internal: symbol visible within the current module
>   • fileprivate: symbol visible within the current file
>   • private: symbol visible within the current declaration
>  
> Moving forward these changes are not difficult to comprehend.  I tend to make 
> _everything_ “private” up front so I don’t have any API leakage.  Then dial 
> back to “fileprivate” as needed.  It’s not difficult for me I guess.

Right. I do that myself more than I would like to admit.
But when we only loosen up/tighten down during coding then access levels are 
almost useless.
The point of access level control is in the design, not in the coding.
If we made a design (including access levels) and then have to dial back, that 
should be a warning that something is wrong.
To me, this is an argument in favour of the proposal.

Rien.



>   As such, I don’t believe that this change was “Actively Harmful”,  
> especially for new developers who have a clean slate or simply are leaving 
> everything unmarked (internal) anyhow until they move up to more advanced 
> topics.  Unraveling a generic or functional code someone else wrote uses way 
> more cognitive power. 
>  
> I’d like to address the suggestion that the migration for SE-0159 could 
> “simply” be a search and replace without loss of functionality.  This doesn’t 
> make sense if you consider the entire code lifecycle.  Sure the code gets 
> migrated and compiles.  This is fine if they code _never_ has to be read 
> again.  But as we know, code is written once and _read many times_ as it will 
> need to be maintained.  The distinction between private and fileprivate 
> contains information, and although it may work correctly now, some 
> information meant to help maintain that code has been lost if these keywords 
> are merged and the functionality of scoped access is removed.  So yes if you 
> don’t maintain the code where this migration takes place, this would be ok. 
> But Swift strives for readability.  Moving classes to separate files to 
> address these issues, creates a multitude of Bunny classes where again for 
> readability some classes belong together in the same file for ease of 
> comprehension (again, code is written once , read many times)
>  
> * Does this proposal fit well with the feel and direction of Swift?
> The spirit of the proposal to simplify access levels is well taken.  This 
> proposal however simplifies at the expense of lost functionality (Scoped 
> Access levels) with no replacement.  The threads talk a about submodules and 
> other solutions that could fill this gap that are not on the roadmap, planned 
> or possible which makes them  non-admissible in considering this proposal.
>  
> * If you have used other languages, libraries, or package managers with a 
> similar feature, how do you feel that this proposal compares to those?
> I am more familiar with scoped access so perhaps that feels more natural to 
> me.  But with the current implementation Swift users can choose whether they 
> use File Based or Scope Based tools, so although not ideal to either side, 
> acceptable until a suitable replacement could be forged.
>  
> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> Re-read SE-0025/proposal/most of this very long thread
>  
>  
>  
>  
> From: <swift-evolution-boun...@swift.org> on behalf of Tino Heth via 
> swift-evolution <swift-evolution@swift.org>
> Reply-To: Tino Heth <2...@gmx.de>
> Date: Monday, March 27, 2017 at 6:48 AM
> To: Zach Waldowski <z...@waldowski.me>
> Cc: <swift-evolution@swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>  
> 
> 
>> I am now absolutely thrilled to create a filter to Mark As Read anything 
>> else arising from this thread. Good luck.
>  
> That might be a good idea —

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 27, 2017, at 2:17 AM, Jonathan Hull  wrote:
> 
> Then you could keep it in the same file.  As you said, the helper type is 
> tiny.
> 
> (or once we have submodules, I suppose you could put it somewhere else in the 
> submodule, if desired)
> 
> Thanks,
> Jon

But then the helper type’s contents cannot be encapsulated.

This use case simply cannot be fulfilled without a scoped access modifier.

Charles

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Steven Knodl via swift-evolution]

Late to the party here 

 

* What is your evaluation of the proposal?

I’m -1 on this.  The proposal is not a difficult read, but may have been simply 
more simply named “Remove Scoped Access Level/Revert SE-0025” as that is what 
is being proposed. “Fix” seems to me to be a unfortunately worded judgmental 
proposal title.

 

* Is the problem being addressed significant enough to warrant a change?

No.  I consider myself to be a fairly “new/n00b” Obj-C/Swift developer. 
Although SE-0025 was a change that required source changes when implemented, 
the reasoning was not difficult to understand and changes were simple to make 
once identified.   Here they are from SE-0025

 
public: symbol visible outside the current module
internal: symbol visible within the current module
fileprivate: symbol visible within the current file
private: symbol visible within the current declaration
 

Moving forward these changes are not difficult to comprehend.  I tend to make 
_everything_ “private” up front so I don’t have any API leakage.  Then dial 
back to “fileprivate” as needed.  It’s not difficult for me I guess.   As such, 
I don’t believe that this change was “Actively Harmful”,  especially for new 
developers who have a clean slate or simply are leaving everything unmarked 
(internal) anyhow until they move up to more advanced topics.  Unraveling a 
generic or functional code someone else wrote uses way more cognitive power. 

 

I’d like to address the suggestion that the migration for SE-0159 could 
“simply” be a search and replace without loss of functionality.  This doesn’t 
make sense if you consider the entire code lifecycle.  Sure the code gets 
migrated and compiles.  This is fine if they code _never_ has to be read again. 
 But as we know, code is written once and _read many times_ as it will need to 
be maintained.  The distinction between private and fileprivate contains 
information, and although it may work correctly now, some information meant to 
help maintain that code has been lost if these keywords are merged and the 
functionality of scoped access is removed.  So yes if you don’t maintain the 
code where this migration takes place, this would be ok. But Swift strives for 
readability.  Moving classes to separate files to address these issues, creates 
a multitude of Bunny classes where again for readability some classes belong 
together in the same file for ease of comprehension (again, code is written 
once , read many times)

 

* Does this proposal fit well with the feel and direction of Swift?

The spirit of the proposal to simplify access levels is well taken.  This 
proposal however simplifies at the expense of lost functionality (Scoped Access 
levels) with no replacement.  The threads talk a about submodules and other 
solutions that could fill this gap that are not on the roadmap, planned or 
possible which makes them  non-admissible in considering this proposal.

 

* If you have used other languages, libraries, or package managers with a 
similar feature, how do you feel that this proposal compares to those?

I am more familiar with scoped access so perhaps that feels more natural to me. 
 But with the current implementation Swift users can choose whether they use 
File Based or Scope Based tools, so although not ideal to either side, 
acceptable until a suitable replacement could be forged.

 

* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

Re-read SE-0025/proposal/most of this very long thread

 

 

 

 

From: <swift-evolution-boun...@swift.org> on behalf of Tino Heth via 
swift-evolution <swift-evolution@swift.org>
Reply-To: Tino Heth <2...@gmx.de>
Date: Monday, March 27, 2017 at 6:48 AM
To: Zach Waldowski <z...@waldowski.me>
Cc: <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

 



I am now absolutely thrilled to create a filter to Mark As Read anything else 
arising from this thread. Good luck.

 

That might be a good idea — after more than 200 messages, and a quite circular 
discussion with an unhealthy amount of ignorance for the opposing side ;-).

 

To fight the latter, I just tried to take the position that "new private" is 
really important, and this imho leads to interesting consequences...

This access modifier really doesn't solve a problem, like "let" does (unless 
the problem you want to solve is having a language with private access).

Have a look at this:

 

public struct SeperateConcerns {

   private var foo: Int = 0

   public mutating func updateFoo(_ value: Int) {

      print("The only allowed way to change foo was invoked")

      foo = value

   }

 

   private var bar: Int = 0

   public mutating func updateBar(_ value: Int) {

      print("The only allowed way to change bar was invoked")

      bar = value

   }

 

  

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Tino Heth via swift-evolution]

> I am now absolutely thrilled to create a filter to Mark As Read anything else 
> arising from this thread. Good luck.

That might be a good idea — after more than 200 messages, and a quite circular 
discussion with an unhealthy amount of ignorance for the opposing side ;-).

To fight the latter, I just tried to take the position that "new private" is 
really important, and this imho leads to interesting consequences...
This access modifier really doesn't solve a problem, like "let" does (unless 
the problem you want to solve is having a language with private access).
Have a look at this:

public struct SeperateConcerns {
private var foo: Int = 0
public mutating func updateFoo(_ value: Int) {
print("The only allowed way to change foo was invoked")
foo = value
}

private var bar: Int = 0
public mutating func updateBar(_ value: Int) {
print("The only allowed way to change bar was invoked")
bar = value
}

private var foobar: Int = 0
public mutating func updateFoobar(_ value: Int) {
print("The only allowed way to change foobar was invoked")
foobar = value
}
}

You can protect foo from being changed by code in other files, and from 
extensions in the same file — and if the latter is a concern, there should also 
be a way to limit access to foo to specific function in scope.
Afaik, somebody proposed "partial" type declarations, but without them, the 
meaning of private is rather arbitrary, and the feature is only useful for a 
tiny special case.
If we had partial types, the situation would be different, and if would be 
possible to declare extensions inside a partial declaration of another type, we 
could even remove fileprivate without an replacement (I guess I should write a 
separate mail for this thought…)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Víctor Pimentel Rodríguez via swift-evolution]

> What is your evaluation of the proposal?

+1, it would improve my team's codebase.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

Yes.

In our case we are using extensions very liberally to organize our
code, and we are using fileprivate just for having access to stored
properties from extensions. A quick search tells us that in our main
target:

- fileprivate: 1483 uses
- private: 424 uses

So it's roughly 3.5x for fileprivate for us. Most of those private
uses are private extensions, where we keep all of our private methods
organized (and that way we don't have to specify that level for every
method). But we cannot do the same for stored properties and we are
forced to use the keyword again and again, several lines in a row.

The problem is that *we never want to use fileprivate*, we are just
*forced to use it*. After a while it's a habit, but it's just ugly to
look at and the code is harder to read. We don't want to have that
detail in our head, in the same way that Swift removes other
unimportant details that we had when working with just Objective-C.

Being selfish, expanding the notion of private to extensions within
the same file would be enough for us. But we also don't see any
additional value in having the fileprivate keyword, and while there
are several code styles that lead to good code, we don't think that
code styles that access other types private information leads to good
design.

> Does this proposal fit well with the feel and direction of Swift?

Yes. This changes was implemented having no references from other
languages, and with zero experience in shipping code. Now we have that
experience, and it shows that for a significantly part of the
community this was hurtful. The fact that with a popular code style
fileprivate is used way more than intended tells something about this.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

While I have no experience with any fileprivate/private language, the
current scope distinctions are hard to explain. At first sight it's
weird that for file-level declarations private and fileprivate means
the same, even if it makes sense when you think about it.

The fact that other popular languages with scope-based access don't
have extensions means that maybe we cannot model Swift scopes based on
them.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

In-depth study and shipping experience with private since Swift 2 and
with fileprivate since Swift 3 was released.

-- 
Víctor Pimentel
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon via swift-evolution]

> On Mar 26, 2017, at 9:37 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> For your tiny helper type, you want it to be only visible to the type it 
> helps. If it’s in a separate file, it has to be visible to the entire module.

Would it help to put the type in a separate file, but in an extension on the 
type it's helping? This would at least keep it out of the top level of the 
`internal` namespace, which might make people less likely to use it by accident 
(which I *think* is what you're trying to guard against here).

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

> On Mar 26, 2017, at 9:37 PM, Charles Srstka  wrote:
> 
>> On Mar 26, 2017, at 11:21 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> I wonder if there is a different type of UI solution which might help people 
>> who hate dividing things up into lots of small files.
>> 
>> I find the way that I work is to make a super large file while I work, and 
>> then break it down into smaller files once the main design is in place and 
>> has settled.  I find one file easier while things are in flux, but many 
>> (well grouped) small files easier for reference and maintenance.
>> 
>> If you have used programs like Ulysses or Scrivener, they allow you to 
>> select multiple sections/files and then those sections show one after 
>> another in the editing UI with a divider between them.
>> 
>> I know we don’t have control over Xcode here, but we could certainly 
>> recommend such a feature to those who do.  Basically, if you select a group 
>> (or multiple files), it would show the contents of each file placed in order 
>> so you could edit across them.  
>> 
>> Would something like that help?  (I am mainly trying to get a sense of the 
>> underlying goals of those on both sides of this argument).
> 
> 
> For your tiny helper type, you want it to be only visible to the type it 
> helps. If it’s in a separate file, it has to be visible to the entire module.

Then you could keep it in the same file.  As you said, the helper type is tiny.

(or once we have submodules, I suppose you could put it somewhere else in the 
submodule, if desired)

Thanks,
Jon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 26, 2017, at 11:21 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I wonder if there is a different type of UI solution which might help people 
> who hate dividing things up into lots of small files.
> 
> I find the way that I work is to make a super large file while I work, and 
> then break it down into smaller files once the main design is in place and 
> has settled.  I find one file easier while things are in flux, but many (well 
> grouped) small files easier for reference and maintenance.
> 
> If you have used programs like Ulysses or Scrivener, they allow you to select 
> multiple sections/files and then those sections show one after another in the 
> editing UI with a divider between them.
> 
> I know we don’t have control over Xcode here, but we could certainly 
> recommend such a feature to those who do.  Basically, if you select a group 
> (or multiple files), it would show the contents of each file placed in order 
> so you could edit across them.  
> 
> Would something like that help?  (I am mainly trying to get a sense of the 
> underlying goals of those on both sides of this argument).


For your tiny helper type, you want it to be only visible to the type it helps. 
If it’s in a separate file, it has to be visible to the entire module.

Charles

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

I wonder if there is a different type of UI solution which might help people 
who hate dividing things up into lots of small files.

I find the way that I work is to make a super large file while I work, and then 
break it down into smaller files once the main design is in place and has 
settled.  I find one file easier while things are in flux, but many (well 
grouped) small files easier for reference and maintenance.

If you have used programs like Ulysses or Scrivener, they allow you to select 
multiple sections/files and then those sections show one after another in the 
editing UI with a divider between them.

I know we don’t have control over Xcode here, but we could certainly recommend 
such a feature to those who do.  Basically, if you select a group (or multiple 
files), it would show the contents of each file placed in order so you could 
edit across them.  

Would something like that help?  (I am mainly trying to get a sense of the 
underlying goals of those on both sides of this argument).

Thanks,
Jon


> On Mar 26, 2017, at 7:44 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On Mar 26, 2017, at 8:44 PM, Brent Royal-Gordon  > wrote:
> 
>>> On Mar 26, 2017, at 10:43 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> On Mar 26, 2017, at 10:43 AM, Xiaodi Wu >> > wrote:
>>> 
 This reaches the crux of the issue, doesn't it? The Swift 2 design for 
 access modifiers does exactly what you reject: that design is based on the 
 premise that it is wise for file organization to follow encapsulation.
>>> 
>>> It's always a gamble speculating about the premise of someone else's 
>>> design.  That said, if I had to guess I would imagine maybe it had as much 
>>> to do with the legacy of C-family languages and header files as anything 
>>> else.
>> 
>> 
>> I've seen people say this several times in access control threads, but 
>> personally, I don't think the use of files for access control is a "legacy" 
>> or a coincidence. I think it's a pretty smart move.
>> 
>> By its nature, the `internal` scope is already defined by files: There is a 
>> certain set of files which are compiled together to form the module, and 
>> those files all see the same `internal` scope. Unless we entirely abandon 
>> the idea of Swift as a fully textual language and move to a FoxPro-style 
>> system where code is stored in a structured database, this will always be 
>> true in Swift. I have a hard time imagining an environment for writing Swift 
>> code where there *aren't* files or some equivalent 
>> named-chunk-of-arbitrary-code unit of organization like the "pages" in a 
>> playground.
>> 
>> Using files to scope `private` is thus a natural extension of the `internal` 
>> scope's rules (one group of files defines the `internal` scope; one single 
>> file defines the `private` scope). It also happens to fit well with typical 
>> programmer behavior. Organizing your code into files by concern is generally 
>> considered a best practice, but files do not carry any other semantic 
>> meaning: there's nothing (else) in the language that forces you to put a 
>> given declaration in one file or another. So with file-based `private`, 
>> there are only two reasons to care about which file a piece of code is 
>> in—`private` access and subjective code organization—and these two things 
>> are usually aligned.
> 
> They're usually aligned at one level of granularity but often not at another. 
>  Small helper types are subjectively best placed in the same file as the type 
> they are assisting yet there are still good reasons to encapsulate their 
> state.  Further, they should not be visible beyond the code they are helping. 
>  
> 
> Even if you can properly encapsulate everything as desired using separate 
> files and submodules you are left with code organization that subjectively 
> and pragmatically is suboptimal.  I don't want a bunch of files with 20 line 
> helper types in my project.  This leads to way too much file switching which 
> significantly reduces clarity. 
> 
>> 
>> This point is actually implicitly acknowledged by, for instance, the 
>> submodule proposal Jonathan Hull put forth upthread, where each file is 
>> implicitly its own submodule if not declared to be part of a different one. 
>> Files aren't always the right encapsulation boundary, but they often are.
> 
> I agree that files are often the right boundary for encapsulation and have 
> not argued against allowing us to address file scopes (unless of course we 
> get a submodule solution that makes them redundant).  I also agree that using 
> groups of files to organize code into submodules makes a lot of sense.
> 
> My point is simply that there is nothing inevitable about using them as an 
> access 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 26, 2017, at 9:44 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On Mar 26, 2017, at 8:44 PM, Brent Royal-Gordon  
>> wrote:
>> 
>>> On Mar 26, 2017, at 10:43 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
 On Mar 26, 2017, at 10:43 AM, Xiaodi Wu  wrote:
 
 This reaches the crux of the issue, doesn't it? The Swift 2 design for 
 access modifiers does exactly what you reject: that design is based on the 
 premise that it is wise for file organization to follow encapsulation.
>>> 
>>> It's always a gamble speculating about the premise of someone else's 
>>> design.  That said, if I had to guess I would imagine maybe it had as much 
>>> to do with the legacy of C-family languages and header files as anything 
>>> else.
>> 
>> 
>> I've seen people say this several times in access control threads, but 
>> personally, I don't think the use of files for access control is a "legacy" 
>> or a coincidence. I think it's a pretty smart move.
>> 
>> By its nature, the `internal` scope is already defined by files: There is a 
>> certain set of files which are compiled together to form the module, and 
>> those files all see the same `internal` scope. Unless we entirely abandon 
>> the idea of Swift as a fully textual language and move to a FoxPro-style 
>> system where code is stored in a structured database, this will always be 
>> true in Swift. I have a hard time imagining an environment for writing Swift 
>> code where there *aren't* files or some equivalent 
>> named-chunk-of-arbitrary-code unit of organization like the "pages" in a 
>> playground.
>> 
>> Using files to scope `private` is thus a natural extension of the `internal` 
>> scope's rules (one group of files defines the `internal` scope; one single 
>> file defines the `private` scope). It also happens to fit well with typical 
>> programmer behavior. Organizing your code into files by concern is generally 
>> considered a best practice, but files do not carry any other semantic 
>> meaning: there's nothing (else) in the language that forces you to put a 
>> given declaration in one file or another. So with file-based `private`, 
>> there are only two reasons to care about which file a piece of code is 
>> in—`private` access and subjective code organization—and these two things 
>> are usually aligned.
> 
> They're usually aligned at one level of granularity but often not at another. 
>  Small helper types are subjectively best placed in the same file as the type 
> they are assisting yet there are still good reasons to encapsulate their 
> state.  Further, they should not be visible beyond the code they are helping. 
>  
> 
> Even if you can properly encapsulate everything as desired using separate 
> files and submodules you are left with code organization that subjectively 
> and pragmatically is suboptimal.  I don't want a bunch of files with 20 line 
> helper types in my project.  This leads to way too much file switching which 
> significantly reduces clarity. 

I should have also mentioned that helper types are not the only use case for 
scoped access.  I often use `private` to hide encapsulates state of a type from 
much of the implementation of the type itself.  The state and basis methods 
that operate on it are placed in the type declaration.  Other methods which are 
defined in terms of the basis methods are placed in extensions.  The basis 
methods may or may not be visible outside the file.

All of the concerns relevant for helper types are relevant for this use case.  
It is a very useful way to organize code.  It would be unfortunate to see the 
language lose the excellent support it currently has for this style of 
programming.

> 
>> 
>> This point is actually implicitly acknowledged by, for instance, the 
>> submodule proposal Jonathan Hull put forth upthread, where each file is 
>> implicitly its own submodule if not declared to be part of a different one. 
>> Files aren't always the right encapsulation boundary, but they often are.
> 
> I agree that files are often the right boundary for encapsulation and have 
> not argued against allowing us to address file scopes (unless of course we 
> get a submodule solution that makes them redundant).  I also agree that using 
> groups of files to organize code into submodules makes a lot of sense.
> 
> My point is simply that there is nothing inevitable about using them as an 
> access control boundary.  There are tradeoffs involved.  Having files be the 
> largest addressable scope smaller than the module is largely responsible for 
> the long file problem in Swift code.  Certainly far more responsible than 
> scoped access control.  (This point was made in response to John's reference 
> to 10,000 line files).
> 
> I have nothing at all against all the uses of files you describe above.  I 
> just don't think files are 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

I admit feeling great dismay at finally posting "MY REVIEW", given the
generally sour nature of the discourse of the thread. However, I feel
like it was a mistake to not have voiced my concern in the SE-0025
fight, so here we are.


On Mon, Mar 20, 2017, at 07:54 PM, Douglas Gregor via swift-evolution wrote:
>  * What is your evaluation of the proposal?


Overwhelmingly vehement +1 for any implementation this idea can take. I
personally prefer reverting to Swift 2 behavior, full-stop.


As others have noted, the text of the proposal leaves a little to be
desired on some of the context. However, I do not believe this prevents
making a decision on the matter. ("To post a proposal to Swift
Evolution, one must first invent the universe…)

>  * Is the problem being addressed significant enough to warrant a
>change to Swift?


The lack of proper consideration, caution, or even solid
implementation of the scoped access modifier is the biggest mistake
the Evolution community has made yet. It is a non-trivially broken
feature with no plans to fix it. If I had to choose between the 15-ish
implemented proposals created wholly by the community and not having
ever had SE-0025 be a twinkle in anyone's eye, I'm honestly not sure
which I'd choose.

>  * Does this proposal fit well with the feel and direction of Swift?


In the most literal sense, it does not, but that's the point: Swift's
thought on access control is in need of a course correction, for reasons
I lay out in the next question.

>  * If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?


I've had plenty of experience in other languages both with and without
access control.


This specific smell in Swift's access control is a sign of a simply
untenable direction. I find C++ access control similarly untenable due
to its confusing variations and edge cases. Swift is heading down a
similar path.


Swift has the laudable goal of being a multi-modal and multi-paradigm
language. That does not mean it cannot be opinionated. Inspecting access
control in a single file is trivial, and if it's not, that's your
problem. I don't care at this point to hear the gospel of all the magic
I can accomplish in unmaintainable large files.


I keep thinking of SE-0009, which was rejected quite plainly for
"introduc[ing] a significant amount of verbosity that does not justify
itself with added clarity". After being immersed in this topic for what
feels like eons, and having my own opinions explained to me several
times, I truly cannot see how scope-private/the fileprivate change was
any different.


Nowadays, my codebases are littered with chains of attributes like
`@IBOutlet fileprivate private(set) weak var`. It look less like working
in a language of sane defaults and look more like I had a stroke while
typing it out. This change has been the antithesis of clarity, and the
inability of +1-ers to see it any other way than theirs is an upsetting
application of, "F*** you, got mine." I'm glad you all understand the
change and have incorporated it into your work, I really am. I haven't;
I still don't.

>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?


I have followed the thread(s) closely, and done much follow-up and
discussion about this issue off the mailing lists.


I beseech the Core Team to act decisively to restore sanity to this part
of the language. I don't care if that means being for or against this
particular proposal. I don't care if it's a spelling change, hinting at
a future plan for submodules, or explaining what the happy path will be
for creating modules  in Xcode 9. I just ask that they think of the
developers who are being underrepresented in this discussion out of
inexperience, lack of understanding, or, worse, having stopped using
Swift in frustration.


I am now absolutely thrilled to create a filter to Mark As Read anything
else arising from this thread. Good luck.


Sincerely,

  Zachary Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 26, 2017, at 8:44 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Mar 26, 2017, at 10:43 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>>> On Mar 26, 2017, at 10:43 AM, Xiaodi Wu  wrote:
>>> 
>>> This reaches the crux of the issue, doesn't it? The Swift 2 design for 
>>> access modifiers does exactly what you reject: that design is based on the 
>>> premise that it is wise for file organization to follow encapsulation.
>> 
>> It's always a gamble speculating about the premise of someone else's design. 
>>  That said, if I had to guess I would imagine maybe it had as much to do 
>> with the legacy of C-family languages and header files as anything else.
> 
> 
> I've seen people say this several times in access control threads, but 
> personally, I don't think the use of files for access control is a "legacy" 
> or a coincidence. I think it's a pretty smart move.
> 
> By its nature, the `internal` scope is already defined by files: There is a 
> certain set of files which are compiled together to form the module, and 
> those files all see the same `internal` scope. Unless we entirely abandon the 
> idea of Swift as a fully textual language and move to a FoxPro-style system 
> where code is stored in a structured database, this will always be true in 
> Swift. I have a hard time imagining an environment for writing Swift code 
> where there *aren't* files or some equivalent named-chunk-of-arbitrary-code 
> unit of organization like the "pages" in a playground.
> 
> Using files to scope `private` is thus a natural extension of the `internal` 
> scope's rules (one group of files defines the `internal` scope; one single 
> file defines the `private` scope). It also happens to fit well with typical 
> programmer behavior. Organizing your code into files by concern is generally 
> considered a best practice, but files do not carry any other semantic 
> meaning: there's nothing (else) in the language that forces you to put a 
> given declaration in one file or another. So with file-based `private`, there 
> are only two reasons to care about which file a piece of code is in—`private` 
> access and subjective code organization—and these two things are usually 
> aligned.

They're usually aligned at one level of granularity but often not at another.  
Small helper types are subjectively best placed in the same file as the type 
they are assisting yet there are still good reasons to encapsulate their state. 
 Further, they should not be visible beyond the code they are helping.  

Even if you can properly encapsulate everything as desired using separate files 
and submodules you are left with code organization that subjectively and 
pragmatically is suboptimal.  I don't want a bunch of files with 20 line helper 
types in my project.  This leads to way too much file switching which 
significantly reduces clarity. 

> 
> This point is actually implicitly acknowledged by, for instance, the 
> submodule proposal Jonathan Hull put forth upthread, where each file is 
> implicitly its own submodule if not declared to be part of a different one. 
> Files aren't always the right encapsulation boundary, but they often are.

I agree that files are often the right boundary for encapsulation and have not 
argued against allowing us to address file scopes (unless of course we get a 
submodule solution that makes them redundant).  I also agree that using groups 
of files to organize code into submodules makes a lot of sense.

My point is simply that there is nothing inevitable about using them as an 
access control boundary.  There are tradeoffs involved.  Having files be the 
largest addressable scope smaller than the module is largely responsible for 
the long file problem in Swift code.  Certainly far more responsible than 
scoped access control.  (This point was made in response to John's reference to 
10,000 line files).

I have nothing at all against all the uses of files you describe above.  I just 
don't think files are the answer to every use case for access control.  There 
are strong pragmatic reasons for allowing encapsulation of types within a file. 
 

> 
> What *can't* file-based organization do, but explicit or implicit scope 
> boundaries can? Well, they can't nest. But as I've previously argued, 
> limiting access to the confines of a nested scope is often problematic 
> because you can only address the current scope, not a surrounding scope;

This is not an inevitable state of affairs.  Again we have a tradeoff and could 
allow addressing containing scopes if desired.  But let's not have that debate 
right now.

For scopes smaller than a file, the current scope is by far the most useful one 
to address.  It is the one that we must be able to address to protect access to 
the state of helper types or small types that closely collaborate.  In cases 
where this kind of tight encapsulation isn't necessary 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 26, 2017, at 8:44 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> So with file-based `private`, there are only two reasons to care about which 
> file a piece of code is in—`private` access and subjective code 
> organization—and these two things are usually aligned.

This sentence is missing a few key words—“in certain coding styles.”

Charles

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

 Physical 
proximity matters not for logical reasons, but for pragmatic reasons.  Maybe 
someday our tools will have features that make it easier to work with code that 
spans several files but alas we’re not there yet.  This means that 
encapsulation should not be the only consideration.  Pragmatism demands we 
consider human factors as well.

The implicit outer scope at the file boundary is one that only exists because 
it was introduced in Swift 2.  It has precedent in the implementation related 
history of translation units and header files but that does not necessarily 
mean it is the best solution for Swift.  Interestingly, if future tools succeed 
in making file boundaries matter less than they do today this implicit boundary 
would start to seem pretty strange and logical scopes would take on increased 
importance.  This isn’t an argument against keeping file scopes - they are 
pragmatically important right now for a number of reasons - but it is an 
argument against removing the tool we have for referring to the current lexical 
scope.

There is significant demand for submodules specifically because people want to 
be able to have smaller files without exposing things to the whole module.  
Again we see the language forcing a tradeoff between physical code organization 
and logical bounding of access to a member.  I would be very surprised if 
scoped access bears more responsibility for large Swift files than the choice 
of files as the largest scope addressable by access control that is smaller 
than the module itself.  If you want to encourage people to have smaller files 
this is the place to start.

I don’t think tradeoffs between encapsulation and physical organization should 
be ignored.  As noted in the previous paragraph, coupling them is partly 
responsible for the large file problem we have.  I think the tradeoffs and the 
problems arising from them should be carefully considered.  If they are not, 
they will continue popping up and people will continue asking for changes to 
the language.  The best way to do this (IMO) is to defer the entire topic of 
access control until we can step back and revisit it holistically.  

Ultimately, many programmers want both tight encapsulation and the ability to 
physically organize their code in a way that is both logical and pragmatic.  Is 
this too much to ask from the language (as a long-term goal)?  I hope not.



> 
> John.
> 
>> 
>>> 
>>> John.
>>> 
>>>> 
>>>>> 
>>>>> John.
>>>>>> -Carl
>>>>>> 
>>>>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>>>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>>>>> >>>>> 
>>>>>> From:  Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>>>>> To:  Carl Brown1/US/IBM@IBM
>>>>>> Cc:  Drew Crawford <d...@sealedabstract.com 
>>>>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>>>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>>>>> <mailto:swift-evolution@swift.org>>
>>>>>> Date:  03/25/2017 12:33 AM
>>>>>> Subject:  Re: [swift-evolution] [Review] SE-0159: Fix Private Access 
>>>>>> Levels
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Would it change your opinion on the proposal?
>>>>>> 
>>>>>> 
>>>>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com 
>>>>>> <mailto:carl.bro...@ibm.com>> wrote:
>>>>>> I would very much like to see your proof that the resultant code is 
>>>>>> unchanged in an arbitrary codebase. 
>>>>>> 
>>>>>> -Carl
>>>>>> 
>>>>>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 
>>>>>> at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com 
>>>>>> <mailto:carl.bro...@ibm.com>> wrote: > Maybe this is the core
>>>>>> 
>>>>>> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>>>>> To: Carl Brown1/US/IBM@IBM
>>>>>> Cc: Drew Crawford <d...@sealedabstract.com 
>>>>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>>>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>>>>> <mailto:swift-evolution@swift.org>>
>>>>>> Date: 03/25/2017 12:01 AM
>>>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access 
>>>>>> Levels
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com 
>>>>>> <mailto:carl.bro...@ibm.com>> wrote: 
>>>>>> My point is that, in rolling back the specific portion of SE-0025, 
>>>>>> case-sensitive find-and-replace will be the trickiest thing in most 
>>>>>> codebases, save those that result in invalid redeclarations. The 
>>>>>> behavior of the resultant code is, unless I'm mistaken, provably 
>>>>>> unchanged.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>>> ___
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <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] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

 detect when this has happened and report it as something for the 
>>>>> programmer to look at.  The proposal causes a small regression in 
>>>>> functionality, in that there's no longer any way to protect scopes from 
>>>>> accesses within the file, but (1) it's okay for Swift to be opinionated 
>>>>> about file size and (2) it seems to me that a workable sub-module 
>>>>> proposal should solve that more elegantly while simultaneously addressing 
>>>>> the concerns of the people who dislike acknowledging the existence of 
>>>>> files.
>>>> 
>>>> The opinionated flag sometimes, like being Swifty, is being used to swath 
>>>> away disagreement, but opinions should be reasonable and pragmatic too... 
>>>> opinionated as "you will code this way and you will like it" seems hardly 
>>>> ideal too if abused constantly. Programming is a creative endeavour too.
>>>> 
>>>> Also, removing a feature that is used and is useful because "maybe" a year 
>>>> or more away there could be a feature that may address the concerns of the 
>>>> people we are stripping away the current feature from seems quite harsh 
>>>> and unfriendly at best... not very logical either.
>>> 
>>> Scoped-private is not some awesomely expressive feature.  It's an access 
>>> restriction.  The "opinion" I'm talking about hardly prevents you from 
>>> coding however you like.  It's just this: organizing your code into 
>>> smaller, more self-contained components separated by file is good practice 
>>> anyway, and when you do that, Swift will let you enforce that each 
>>> component is properly encapsulated.
>> 
>> This does not address the case where we have a small helper type that is 
>> only 10s of lines long, is not visible outside the file, and encapsulates an 
>> important part of the implementation using scoped private.  The whole file 
>> is usually only a couple hundred lines.  This is not an excessively long 
>> file and already contains a single component that is presented to the rest 
>> of the program.
>> 
>> Some designs of submodules might allow us to properly encapsulate everything 
>> but if that requires us to put a small helper type in a separate file that 
>> would be a very unfortunate and inflexible constraint on how we are able to 
>> organize our code. 
>> 
>>  I don't want encapsulation concerns dictating how I physically organize my 
>> code.  That is significant and unnecessary complexity if you ask me.  It 
>> forces a tradeoff between desired physical organization and desired 
>> encapsulation.  We should not force users to make this tradeoff.
>> 
>>> 
>>> John.
>>> 
>>>> 
>>>>> 
>>>>> John.
>>>>>> -Carl
>>>>>> 
>>>>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>>>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>>>>> >>>>> 
>>>>>> From: Xiaodi Wu <xiaodi...@gmail.com>
>>>>>> To: Carl Brown1/US/IBM@IBM
>>>>>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull 
>>>>>> <jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
>>>>>> Date: 03/25/2017 12:33 AM
>>>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access 
>>>>>> Levels
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Would it change your opinion on the proposal?
>>>>>> 
>>>>>> 
>>>>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com> 
>>>>>> wrote:
>>>>>> I would very much like to see your proof that the resultant code is 
>>>>>> unchanged in an arbitrary codebase. 
>>>>>> 
>>>>>> -Carl
>>>>>> 
>>>>>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 
>>>>>> at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote: > Maybe this is 
>>>>>> the core
>>>>>> 
>>>>>> From: Xiaodi Wu <xiaodi...@gmail.com>
>>>>>> To: Carl Brown1/US/IBM@IBM
>>>>>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull 
>>>>>> <jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
>>>>>> Date: 03/25/2017 12:01 AM
>>>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access 
>>>>>> Levels
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> 
>>>>>> wrote:  
>>>>>> My point is that, in rolling back the specific portion of SE-0025, 
>>>>>> case-sensitive find-and-replace will be the trickiest thing in most 
>>>>>> codebases, save those that result in invalid redeclarations. The 
>>>>>> behavior of the resultant code is, unless I'm mistaken, provably 
>>>>>> unchanged.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ___
>>>>>> 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
>> ___
>> 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] [Review] SE-0159: Fix Private Access Levels

[Nevin Brackett-Rozinsky via swift-evolution]

On Sun, Mar 26, 2017 at 12:57 PM, David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 26, 2017, at 08:50, David James via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I propose instead that we revise to use Alternative #3, per Vladimir’s
> comment and revision.
>
> Revised version:
>
> *“3. Revert private to be file-based and introduce the scope-based access
> level under a new name (e.g.: scoped, local, etc), provided that the
> scope-based access modifier is not used at the top level of the file.” *
> (addendum via Vladimir’s revised comment)
>
>
> Yeah, within reason, I couldn't care less how "private"/"fileprivate" are
> *spelled*. What I'm against is removing the *functionality* of the
> current "private" without simultaneously providing a semantically
> equivalent replacement.
>


Conversely, I do not particularly care whether the functionality of
scope-based visibility stays or goes, but I find the spelling “fileprivate”
to be an ugly wart on an otherwise beautiful language.

Before the discussion on this review, I had a slight preference for
removing scope-based visibility in order to simplify the access control
model. After reading through the thread I have a slight preference for
keeping that functionality to enable compiler verification that invariants
are only touched via dedicated channels. I do not have a strong opinion
either way, and I would be fine to see scope-based visibility exist under
the name “scoped”, or be removed entirely.

However, the “fileprivate” keyword is one of the few things I actually
*dislike* about Swift. As in, when I am writing code I find it annoying and
offputting to use such a lengthy and inelegant term for one of the most
common access levels. I think it was a mistake to change the meaning of
“private” in SE-0025, and we should change it back posthaste.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[John McCall via swift-evolution]

uld not want 
to encourage programmers to engage in that level of pedantry, because some of 
them will, and they'll make themselves miserable and accomplish nothing of 
value, and they'll blame Swift (correctly) for implying that it was important.

> Some designs of submodules might allow us to properly encapsulate everything 
> but if that requires us to put a small helper type in a separate file that 
> would be a very unfortunate and inflexible constraint on how we are able to 
> organize our code. 
> 
>  I don't want encapsulation concerns dictating how I physically organize my 
> code.  That is significant and unnecessary complexity if you ask me.  It 
> forces a tradeoff between desired physical organization and desired 
> encapsulation.  We should not force users to make this tradeoff.

See, you say this, and you're apparently talking talking about the burdens of 
maintaining a 200-line file.  Someone else says it, and their files are 10,000 
lines long.  I'm going to be opinionated and say that, no, physical 
organization is inherently linked to encapsulation because of the implicit 
outer scope of the file, and that if you care about encapsulation, you should 
also be organizing your code to minimize that outer scope, which will also make 
it trivial to understand how a private declaration is used and recognize in 
code reviews for changes that touch that file that they're accessing something 
they shouldn't.

John.

> 
>> 
>> John.
>> 
>>> 
>>>> 
>>>> John.
>>>>> -Carl
>>>>> 
>>>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>>>> >>>> 
>>>>> From:  Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>>>> To:  Carl Brown1/US/IBM@IBM
>>>>> Cc:  Drew Crawford <d...@sealedabstract.com 
>>>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>>>> <mailto:swift-evolution@swift.org>>
>>>>> Date:  03/25/2017 12:33 AM
>>>>> Subject:  Re: [swift-evolution] [Review] SE-0159: Fix Private Access 
>>>>> Levels
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Would it change your opinion on the proposal?
>>>>> 
>>>>> 
>>>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com 
>>>>> <mailto:carl.bro...@ibm.com>> wrote:
>>>>> I would very much like to see your proof that the resultant code is 
>>>>> unchanged in an arbitrary codebase. 
>>>>> 
>>>>> -Carl
>>>>> 
>>>>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 
>>>>> at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com 
>>>>> <mailto:carl.bro...@ibm.com>> wrote: > Maybe this is the core
>>>>> 
>>>>> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>>>> To: Carl Brown1/US/IBM@IBM
>>>>> Cc: Drew Crawford <d...@sealedabstract.com 
>>>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>>>> <mailto:swift-evolution@swift.org>>
>>>>> Date: 03/25/2017 12:01 AM
>>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com 
>>>>> <mailto:carl.bro...@ibm.com>> wrote: 
>>>>> My point is that, in rolling back the specific portion of SE-0025, 
>>>>> case-sensitive find-and-replace will be the trickiest thing in most 
>>>>> codebases, save those that result in invalid redeclarations. The behavior 
>>>>> of the resultant code is, unless I'm mistaken, provably unchanged.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ___
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> ___
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <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] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 26, 2017, at 12:15 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 26, 2017, at 11:57 AM, David Sweeris via swift-evolution 
>>  wrote:
>> 
>> On Mar 26, 2017, at 08:50, David James via swift-evolution 
>>  wrote:
>> 
>>> • What is your evaluation of the proposal?
>>> -1 as written (see below)
>>> 
>>> • Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> Not as written
>>> 
>>> • Does this proposal fit well with the feel and direction of Swift?
>>> It does in terms of apparent simplicity, but not in terms of practicality. 
>>> I like to think of Swift as a practical language that does not sacrifice 
>>> utility for apparent simplicity.
>>> 
>>> • If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>>> Can’t be compared. Swift has already set a precedent by making “private” 
>>> mean something non-traditional (pre SE-0025), and I think it was a good 
>>> decision, taking us away from the idea that private is only useful with 
>>> parent inheritance structures. 
>>> 
>>> • How much effort did you put into your review? A glance, a quick reading, 
>>> or an in-depth study?
>>> Have been following it since SE-0025, the aftermath, extensive experience 
>>> using the modifiers in framework code I write and reading all related 
>>> threads on SE.
>>> 
>>> ***
>>> 
>>> I propose instead that we revise to use Alternative #3, per Vladimir’s 
>>> comment and revision.
>>> 
>>> Revised version:
>>> 
>>> “3. Revert private to be file-based and introduce the scope-based access 
>>> level under a new name (e.g.: scoped, local, etc), provided that the 
>>> scope-based access modifier is not used at the top level of the file.” 
>>> (addendum via Vladimir’s revised comment)
>> 
>> Yeah, within reason, I couldn't care less how "private"/"fileprivate" are 
>> spelled. What I'm against is removing the functionalityof the current 
>> "private" without simultaneously providing a semantically equivalent 
>> replacement.
> 
> I’ll second that. Don’t care what the scoped access modifier is called, as 
> long as there is one.

Agree.  I don't think any supporters are insisting it be called private.  
Renaming seems like the compromise that satisfies the greatest number of people.

> 
> Charles
> 
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 26, 2017, at 11:57 AM, David Sweeris via swift-evolution 
>  wrote:
> 
> On Mar 26, 2017, at 08:50, David James via swift-evolution 
> > wrote:
> 
>> • What is your evaluation of the proposal?
>> -1 as written (see below)
>> 
>> • Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Not as written
>> 
>> • Does this proposal fit well with the feel and direction of Swift?
>> It does in terms of apparent simplicity, but not in terms of practicality. I 
>> like to think of Swift as a practical language that does not sacrifice 
>> utility for apparent simplicity.
>> 
>> • If you have used other languages or libraries with a similar feature, how 
>> do you feel that this proposal compares to those?
>> Can’t be compared. Swift has already set a precedent by making “private” 
>> mean something non-traditional (pre SE-0025), and I think it was a good 
>> decision, taking us away from the idea that private is only useful with 
>> parent inheritance structures. 
>> 
>> • How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
>> Have been following it since SE-0025, the aftermath, extensive experience 
>> using the modifiers in framework code I write and reading all related 
>> threads on SE.
>> 
>> ***
>> 
>> I propose instead that we revise to use Alternative #3, per Vladimir’s 
>> comment and revision.
>> 
>> Revised version:
>> 
>> “3. Revert private to be file-based and introduce the scope-based access 
>> level under a new name (e.g.: scoped, local, etc), provided that the 
>> scope-based access modifier is not used at the top level of the file.” 
>> (addendum via Vladimir’s revised comment)
> 
> Yeah, within reason, I couldn't care less how "private"/"fileprivate" are 
> spelled. What I'm against is removing the functionalityof the current 
> "private" without simultaneously providing a semantically equivalent 
> replacement.

I’ll second that. Don’t care what the scoped access modifier is called, as long 
as there is one.

Charles

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[David Sweeris via swift-evolution]

> On Mar 26, 2017, at 08:50, David James via swift-evolution 
>  wrote:
> 
> • What is your evaluation of the proposal?
> -1 as written (see below)
> 
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Not as written
> 
> • Does this proposal fit well with the feel and direction of Swift?
> It does in terms of apparent simplicity, but not in terms of practicality. I 
> like to think of Swift as a practical language that does not sacrifice 
> utility for apparent simplicity.
> 
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> Can’t be compared. Swift has already set a precedent by making “private” mean 
> something non-traditional (pre SE-0025), and I think it was a good decision, 
> taking us away from the idea that private is only useful with parent 
> inheritance structures. 
> 
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> Have been following it since SE-0025, the aftermath, extensive experience 
> using the modifiers in framework code I write and reading all related threads 
> on SE.
> 
> ***
> 
> I propose instead that we revise to use Alternative #3, per Vladimir’s 
> comment and revision.
> 
> Revised version:
> 
> “3. Revert private to be file-based and introduce the scope-based access 
> level under a new name (e.g.: scoped, local, etc), provided that the 
> scope-based access modifier is not used at the top level of the file.” 
> (addendum via Vladimir’s revised comment)

Yeah, within reason, I couldn't care less how "private"/"fileprivate" are 
spelled. What I'm against is removing the functionality of the current 
"private" without simultaneously providing a semantically equivalent 
replacement.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[David James via swift-evolution]

uot; I'm talking about hardly prevents you from 
>> coding however you like.  It's just this: organizing your code into smaller, 
>> more self-contained components separated by file is good practice anyway, 
>> and when you do that, Swift will let you enforce that each component is 
>> properly encapsulated.
> 
> This does not address the case where we have a small helper type that is only 
> 10s of lines long, is not visible outside the file, and encapsulates an 
> important part of the implementation using scoped private.  The whole file is 
> usually only a couple hundred lines.  This is not an excessively long file 
> and already contains a single component that is presented to the rest of the 
> program.
> 
> Some designs of submodules might allow us to properly encapsulate everything 
> but if that requires us to put a small helper type in a separate file that 
> would be a very unfortunate and inflexible constraint on how we are able to 
> organize our code. 
> 
>  I don't want encapsulation concerns dictating how I physically organize my 
> code.  That is significant and unnecessary complexity if you ask me.  It 
> forces a tradeoff between desired physical organization and desired 
> encapsulation.  We should not force users to make this tradeoff.
> 
>> 
>> John.
>> 
>>> 
>>>> 
>>>> John.
>>>>> -Carl
>>>>> 
>>>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>>>> >>>> 
>>>>> From:  Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>>>> To:  Carl Brown1/US/IBM@IBM
>>>>> Cc:  Drew Crawford <d...@sealedabstract.com 
>>>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>>>> <mailto:swift-evolution@swift.org>>
>>>>> Date:  03/25/2017 12:33 AM
>>>>> Subject:  Re: [swift-evolution] [Review] SE-0159: Fix Private Access 
>>>>> Levels
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Would it change your opinion on the proposal?
>>>>> 
>>>>> 
>>>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com 
>>>>> <mailto:carl.bro...@ibm.com>> wrote:
>>>>> I would very much like to see your proof that the resultant code is 
>>>>> unchanged in an arbitrary codebase. 
>>>>> 
>>>>> -Carl
>>>>> 
>>>>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 
>>>>> at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com 
>>>>> <mailto:carl.bro...@ibm.com>> wrote: > Maybe this is the core
>>>>> 
>>>>> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>>>> To: Carl Brown1/US/IBM@IBM
>>>>> Cc: Drew Crawford <d...@sealedabstract.com 
>>>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>>>> <mailto:swift-evolution@swift.org>>
>>>>> Date: 03/25/2017 12:01 AM
>>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com 
>>>>> <mailto:carl.bro...@ibm.com>> wrote: 
>>>>> My point is that, in rolling back the specific portion of SE-0025, 
>>>>> case-sensitive find-and-replace will be the trickiest thing in most 
>>>>> codebases, save those that result in invalid redeclarations. The behavior 
>>>>> of the resultant code is, unless I'm mistaken, provably unchanged.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ___
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> ___
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
David James

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

ould it change your
> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1
> 
> From: Xiaodi Wu <xiaodi...@gmail.com>
> To: Carl Brown1/US/IBM@IBM
> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>,
> swift-evolution <swift-evolution@swift.org>
> Date: 03/25/2017 12:33 AM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> --
>
>
>
> Would it change your opinion on the proposal?
>
>
> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <*carl.bro...@ibm.com*
> <carl.bro...@ibm.com>> wrote:
>
>I would very much like to see your proof that the resultant code is
>unchanged in an arbitrary codebase.
>
>-Carl
>
>Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24,
>2017 at 11:55 PM, Carl Brown1 <*carl.bro...@ibm.com*
><carl.bro...@ibm.com>> wrote: > Maybe this is the core
>
>From: Xiaodi Wu <*xiaodi...@gmail.com* <xiaodi...@gmail.com>>
>To: Carl Brown1/US/IBM@IBM
>Cc: Drew Crawford <*d...@sealedabstract.com* <d...@sealedabstract.com>>,
>Jonathan Hull <*jh...@gbis.com* <jh...@gbis.com>>, swift-evolution <
>*swift-evolution@swift.org* <swift-evolution@swift.org>>
>Date: 03/25/2017 12:01 AM
>Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access
>Levels
>--
>
>
>
>On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <*carl.bro...@ibm.com*
><carl.bro...@ibm.com>> wrote:
>
>My point is that, in rolling back the specific portion of SE-0025,
>case-sensitive find-and-replace will be the trickiest thing in most
>codebases, save those that result in invalid redeclarations. The behavior
>of the resultant code is, unless I'm mistaken, provably unchanged.
>
>
>
>
>
> ___
> 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
>
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 26, 2017, at 4:13 AM, John McCall via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> On Mar 26, 2017, at 4:27 AM, Goffredo Marocchi <pana...@gmail.com> wrote:
>>> On 26 Mar 2017, at 06:54, John McCall via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> Yes, it would change my opinion of it. I wouldn't become a strong 
>>>> supporter because I don't see any value in it, but a rigorous proof that 
>>>> this proposal could not possibly introduce regressions to any existing 
>>>> codebases would change my opinion from "strongly against" to "doesn't 
>>>> matter to me, I'll stop arguing against it and go get my real work done".
>>>> 
>>> Speaking just for myself, this was a key part of why I was attracted to 
>>> this proposal: it seemed to me to be extremely unlikely to cause 
>>> regressions in behavior.  Even without any special behavior in the 
>>> migrator, code will mostly work exactly as before: things that would have 
>>> been invalid before will become valid, but not the other way around.  The 
>>> exception is that old-private declarations from scopes in the same file can 
>>> now be found by lookups in different scopes (but still only within the same 
>>> file).  It should be quite straightforward for the migrator to detect when 
>>> this has happened and report it as something for the programmer to look at. 
>>>  The proposal causes a small regression in functionality, in that there's 
>>> no longer any way to protect scopes from accesses within the file, but (1) 
>>> it's okay for Swift to be opinionated about file size and (2) it seems to 
>>> me that a workable sub-module proposal should solve that more elegantly 
>>> while simultaneously addressing the concerns of the people who dislike 
>>> acknowledging the existence of files.
>> 
>> The opinionated flag sometimes, like being Swifty, is being used to swath 
>> away disagreement, but opinions should be reasonable and pragmatic too... 
>> opinionated as "you will code this way and you will like it" seems hardly 
>> ideal too if abused constantly. Programming is a creative endeavour too.
>> 
>> Also, removing a feature that is used and is useful because "maybe" a year 
>> or more away there could be a feature that may address the concerns of the 
>> people we are stripping away the current feature from seems quite harsh and 
>> unfriendly at best... not very logical either.
> 
> Scoped-private is not some awesomely expressive feature.  It's an access 
> restriction.  The "opinion" I'm talking about hardly prevents you from coding 
> however you like.  It's just this: organizing your code into smaller, more 
> self-contained components separated by file is good practice anyway, and when 
> you do that, Swift will let you enforce that each component is properly 
> encapsulated.

This does not address the case where we have a small helper type that is only 
10s of lines long, is not visible outside the file, and encapsulates an 
important part of the implementation using scoped private.  The whole file is 
usually only a couple hundred lines.  This is not an excessively long file and 
already contains a single component that is presented to the rest of the 
program.

Some designs of submodules might allow us to properly encapsulate everything 
but if that requires us to put a small helper type in a separate file that 
would be a very unfortunate and inflexible constraint on how we are able to 
organize our code. 

 I don't want encapsulation concerns dictating how I physically organize my 
code.  That is significant and unnecessary complexity if you ask me.  It forces 
a tradeoff between desired physical organization and desired encapsulation.  We 
should not force users to make this tradeoff.

> 
> John.
> 
>> 
>>> 
>>> John.
>>>> -Carl
>>>> 
>>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>>> >>> 
>>>> From: Xiaodi Wu <xiaodi...@gmail.com>
>>>> To: Carl Brown1/US/IBM@IBM
>>>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull 
>>>> <jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
>>>> Date: 03/25/2017 12:33 AM
>>>> Subject: Re: [swift-evolution] [

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 26 Mar 2017, at 13:23, Andrey Tarantsov via swift-evolution 
>  wrote:
> 
> > What is your evaluation of the proposal?
> 
> Very strong -1. Drew has said it all.
> 
> A few extra points:
> 
> * If you split a class into a bunch of extensions, chances are it's a large 
> class, and fileprivate keyword provides crucial documentation on which 
> methods and fields are accessed from outside the scope. Even if someone 
> blindly uses private until compiler complains, then switches to fileprivate 
> without thinking, there's still value when reading the code. (This has been 
> mentioned as one of the points against scoped private.)

it should, but fileprivate only means that something can be done, not that 
something is done.
And unfortunately or not, people will use this keyword in the wrong way, forget 
to update access levels after changes etc.
So while this should be true in theory, in praxis it is almost never the case.

Rien.

> 
> * Encapsulation is in the spirit of Swift's safety goals, we want to 
> encourage it.
> 
> * // MARK is perfectly fine for tightly-coupled class bodies, so if you find 
> yourself using tons of fileprivate, consider switching to a single body with 
> marks
> 
> * I really like the point that we should uphold the original decision unless 
> we find new compelling arguments that were not considered initially.
> 
> 
> > Is the problem being addressed significant enough to warrant a change to 
> > Swift?
> 
> No. I haven't personally seen any complains about this feature in my circles; 
> everyone is happy about tighter access controls.
> 
> 
> > Does this proposal fit well with the feel and direction of Swift?
> 
> It feels actively against the safety and readability goals of Swift.
> 
> 
> > If you have used other languages or libraries with a similar feature, how 
> > do you feel that this proposal compares to those?
> 
> This has been beaten to death in the original proposal.
> 
> 
> > How much effort did you put into your review? A glance, a quick reading, or 
> > an in-depth study?
> 
> Thorough reading of the first half of this discussion, and active 
> participation in the original discussion (as well as writing and shipping 
> lots of Swift code since Swift 0.x).
> 
> A.
> 
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Andrey Tarantsov via swift-evolution]

> What is your evaluation of the proposal?



Very strong -1. Drew has said it all.



A few extra points:



* If you split a class into a bunch of extensions, chances are it's a
  large class, and fileprivate keyword provides crucial *documentation*
  on which methods and fields are accessed from outside the scope. Even
  if someone blindly uses private until compiler complains, then
  switches to fileprivate without thinking, there's still value when
  reading the code. (This has been mentioned as one of the points
  against scoped private.)


* Encapsulation is in the spirit of Swift's safety goals, we want to
  encourage it.


* // MARK is perfectly fine for tightly-coupled class bodies, so if you
  find yourself using tons of fileprivate, consider switching to a
  single body with marks


* I really like the point that we should uphold the original decision
  unless we find new compelling arguments that were not considered
  initially.




> Is the problem being addressed significant enough to warrant a change
> to Swift?


No. I haven't personally seen any complains about this feature in my
circles; everyone is happy about tighter access controls.




> Does this proposal fit well with the feel and direction of Swift?



It feels actively against the safety and readability goals of Swift.





> If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?


This has been beaten to death in the original proposal.





> How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?


Thorough reading of the first half of this discussion, and active
participation in the original discussion (as well as writing and
shipping lots of Swift code since Swift 0.x).


A.


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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon via swift-evolution]

> On Mar 24, 2017, at 4:12 AM, Vinnie Hesener via swift-evolution 
>  wrote:
> 
> Why can't we just start naming access modifiers literally: a location in the 
> code that they apply to. Examples such as "scope" or "insidethecurlybraces" 
> or "file" or "module" or "submodule" or "codebase". Any of these or other 
> synonyms would be much more Swifty in my opinion. 

Using just the nouns might make it look like you're declaring those things, but 
I suggested (iirc) `scopewide`, `filewide`, and `modulewide` during the SE-0025 
review. The core team considered and rejected those suggestions.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[John McCall via swift-evolution]

> On Mar 26, 2017, at 4:27 AM, Goffredo Marocchi <pana...@gmail.com> wrote:
> On 26 Mar 2017, at 06:54, John McCall via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> Yes, it would change my opinion of it. I wouldn't become a strong supporter 
>>> because I don't see any value in it, but a rigorous proof that this 
>>> proposal could not possibly introduce regressions to any existing codebases 
>>> would change my opinion from "strongly against" to "doesn't matter to me, 
>>> I'll stop arguing against it and go get my real work done".
>>> 
>> Speaking just for myself, this was a key part of why I was attracted to this 
>> proposal: it seemed to me to be extremely unlikely to cause regressions in 
>> behavior.  Even without any special behavior in the migrator, code will 
>> mostly work exactly as before: things that would have been invalid before 
>> will become valid, but not the other way around.  The exception is that 
>> old-private declarations from scopes in the same file can now be found by 
>> lookups in different scopes (but still only within the same file).  It 
>> should be quite straightforward for the migrator to detect when this has 
>> happened and report it as something for the programmer to look at.  The 
>> proposal causes a small regression in functionality, in that there's no 
>> longer any way to protect scopes from accesses within the file, but (1) it's 
>> okay for Swift to be opinionated about file size and (2) it seems to me that 
>> a workable sub-module proposal should solve that more elegantly while 
>> simultaneously addressing the concerns of the people who dislike 
>> acknowledging the existence of files.
> 
> The opinionated flag sometimes, like being Swifty, is being used to swath 
> away disagreement, but opinions should be reasonable and pragmatic too... 
> opinionated as "you will code this way and you will like it" seems hardly 
> ideal too if abused constantly. Programming is a creative endeavour too.
> 
> Also, removing a feature that is used and is useful because "maybe" a year or 
> more away there could be a feature that may address the concerns of the 
> people we are stripping away the current feature from seems quite harsh and 
> unfriendly at best... not very logical either.

Scoped-private is not some awesomely expressive feature.  It's an access 
restriction.  The "opinion" I'm talking about hardly prevents you from coding 
however you like.  It's just this: organizing your code into smaller, more 
self-contained components separated by file is good practice anyway, and when 
you do that, Swift will let you enforce that each component is properly 
encapsulated.

John.

> 
>> 
>> John.
>>> -Carl
>>> 
>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>> >> 
>>> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>> To: Carl Brown1/US/IBM@IBM
>>> Cc: Drew Crawford <d...@sealedabstract.com 
>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>> <mailto:swift-evolution@swift.org>>
>>> Date: 03/25/2017 12:33 AM
>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>>> 
>>> 
>>> 
>>> 
>>> Would it change your opinion on the proposal?
>>> 
>>> 
>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com 
>>> <mailto:carl.bro...@ibm.com>> wrote:
>>> I would very much like to see your proof that the resultant code is 
>>> unchanged in an arbitrary codebase. 
>>> 
>>> -Carl
>>> 
>>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 
>>> 11:55 PM, Carl Brown1 <carl.bro...@ibm.com <mailto:carl.bro...@ibm.com>> 
>>> wrote: > Maybe this is the core
>>> 
>>> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>> To: Carl Brown1/US/IBM@IBM
>>> Cc: Drew Crawford <d...@sealedabstract.com 
>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>> <mailto:jh...@gbis.com>>, swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[John McCall via swift-evolution]

> On Mar 26, 2017, at 4:23 AM, jaden.gel...@gmail.com wrote:
> 
> 
> 
> On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> Yes, it would change my opinion of it. I wouldn't become a strong supporter 
>>> because I don't see any value in it, but a rigorous proof that this 
>>> proposal could not possibly introduce regressions to any existing codebases 
>>> would change my opinion from "strongly against" to "doesn't matter to me, 
>>> I'll stop arguing against it and go get my real work done".
>>> 
>> Speaking just for myself, this was a key part of why I was attracted to this 
>> proposal: it seemed to me to be extremely unlikely to cause regressions in 
>> behavior.  Even without any special behavior in the migrator, code will 
>> mostly work exactly as before: things that would have been invalid before 
>> will become valid, but not the other way around.
> 
> What about overloads that become ambiguous? I admit this is a fringe case.

I wouldn't say it's a fringe case.  However, if the program no longer 
type-checks after migration, that's a pretty clear way of informing the user 
that something funny is going on and they need to look at it.  Suppose instead 
that the program continues to type-check after migration, but now it uses 
different declarations.  If the declarations would previously have 
inaccessible, recall that I suggested that the migrator could easily detect 
that and warn the programmer about the change in behavior.  If the declarations 
were previously accessible, and it's just that somehow a new ambiguity caused 
the type-checker to prefer a different solution — well, that's starting to feel 
pretty fringe.  If we considered things like that to be completely blocking, 
we'd be unable to ever change the standard library at all.

Remember that the concern here is just that programs will silently change 
behavior because of migration.  Migration is allowed to say that the programs 
need to be manually fixed; we just don't want that to happen too often, because 
it's annoying to have to fix a million things when you update.  Is anyone 
actually arguing that this sort of thing is so pervasive in their code that we 
need to worry about that?

John.

> 
>> The exception is that old-private declarations from scopes in the same file 
>> can now be found by lookups in different scopes (but still only within the 
>> same file).  It should be quite straightforward for the migrator to detect 
>> when this has happened and report it as something for the programmer to look 
>> at.  The proposal causes a small regression in functionality, in that 
>> there's no longer any way to protect scopes from accesses within the file, 
>> but (1) it's okay for Swift to be opinionated about file size and (2) it 
>> seems to me that a workable sub-module proposal should solve that more 
>> elegantly while simultaneously addressing the concerns of the people who 
>> dislike acknowledging the existence of files.
>> 
>> John.
>>> -Carl
>>> 
>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>> >> 
>>> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
>>> To: Carl Brown1/US/IBM@IBM
>>> Cc: Drew Crawford <d...@sealedabstract.com 
>>> <mailto:d...@sealedabstract.com>>, Jonathan Hull <jh...@gbis.com 
>>> <mailto:jh...@gbis.com>>, swift-evolution <swift-evolution@swift.org 
>>> <mailto:swift-evolution@swift.org>>
>>> Date: 03/25/2017 12:33 AM
>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>>> 
>>> 
>>> 
>>> 
>>> Would it change your opinion on the proposal?
>>> 
>>> 
>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com 
>>> <mailto:carl.bro...@ibm.com>> wrote:
>>> I would very much like to see your proof that the resultant code is 
>>> unchanged in an arbitrary codebase. 
>>> 
>>> -Carl
>>> 
>>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 
>>> 11:55 PM, Carl Brown1 <carl.bro...@ibm.com <mailto:carl.bro...@ibm.com>> 
>>> wrote: > Maybe this is the core
>>> 
>>> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jaden Geller via swift-evolution]

This will not always work, particularly when both symbols already have an 
identical type. 

> On Mar 26, 2017, at 1:29 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> I think this is where some special behavior in the migrator is called for. 
> Where an overload ambiguity appears, it will need to insert an "as T" to 
> disambiguate.
> 
> Carl's standard can be strictly met by a migrator that compares all uses of 
> private facilities under the new and old meaning of private, ensuring that no 
> uses emerge or disappear after rollback.
>> On Sun, Mar 26, 2017 at 03:23 Jaden Geller via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>> On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>>>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> Yes, it would change my opinion of it. I wouldn't become a strong 
>>>> supporter because I don't see any value in it, but a rigorous proof that 
>>>> this proposal could not possibly introduce regressions to any existing 
>>>> codebases would change my opinion from "strongly against" to "doesn't 
>>>> matter to me, I'll stop arguing against it and go get my real work done".
>>>> 
>>> Speaking just for myself, this was a key part of why I was attracted to 
>>> this proposal: it seemed to me to be extremely unlikely to cause 
>>> regressions in behavior.  Even without any special behavior in the 
>>> migrator, code will mostly work exactly as before: things that would have 
>>> been invalid before will become valid, but not the other way around.
>> 
>> What about overloads that become ambiguous? I admit this is a fringe case.
>> 
>>> The exception is that old-private declarations from scopes in the same file 
>>> can now be found by lookups in different scopes (but still only within the 
>>> same file).  It should be quite straightforward for the migrator to detect 
>>> when this has happened and report it as something for the programmer to 
>>> look at.  The proposal causes a small regression in functionality, in that 
>>> there's no longer any way to protect scopes from accesses within the file, 
>>> but (1) it's okay for Swift to be opinionated about file size and (2) it 
>>> seems to me that a workable sub-module proposal should solve that more 
>>> elegantly while simultaneously addressing the concerns of the people who 
>>> dislike acknowledging the existence of files.
>>> 
>>> John.
>>>> -Carl
>>>> 
>>>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>>>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>>>> >>> 
>>>> From: Xiaodi Wu <xiaodi...@gmail.com>
>>>> To: Carl Brown1/US/IBM@IBM
>>>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull 
>>>> <jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
>>>> Date: 03/25/2017 12:33 AM
>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Would it change your opinion on the proposal?
>>>> 
>>>> 
>>>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com> wrote:
>>>> I would very much like to see your proof that the resultant code is 
>>>> unchanged in an arbitrary codebase. 
>>>> 
>>>> -Carl
>>>> 
>>>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 
>>>> 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote: > Maybe this is the core
>>>> 
>>>> From: Xiaodi Wu <xiaodi...@gmail.com>
>>>> To: Carl Brown1/US/IBM@IBM
>>>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull 
>>>> <jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
>>>> Date: 03/25/2017 12:01 AM
>>>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>>>> 
>>>> 
>>>> 
>>>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote:
>>>> My point is that, in rolling back the specific portion of SE-0025, 
>>>> case-sensitive find-and-replace will be the trickiest thing in most 
>>>> codebases, save those that result in invalid redeclarations. The behavior 
>>>> of the resultant code is, unless I'm mistaken, provably unchanged.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

I think this is where some special behavior in the migrator is called for.
Where an overload ambiguity appears, it will need to insert an "as T" to
disambiguate.

Carl's standard can be strictly met by a migrator that compares all uses of
private facilities under the new and old meaning of private, ensuring that
no uses emerge or disappear after rollback.
On Sun, Mar 26, 2017 at 03:23 Jaden Geller via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Yes, it would change my opinion of it. I wouldn't become a strong
> supporter because I don't see any value in it, but a rigorous proof that
> this proposal could not possibly introduce regressions to any existing
> codebases would change my opinion from "strongly against" to "doesn't
> matter to me, I'll stop arguing against it and go get my real work done".
>
> Speaking just for myself, this was a key part of why I was attracted to
> this proposal: it seemed to me to be extremely unlikely to cause
> regressions in behavior.  Even without any special behavior in the
> migrator, code will mostly work exactly as before: things that would have
> been invalid before will become valid, but not the other way around.
>
>
> What about overloads that become ambiguous? I admit this is a fringe case.
>
> The exception is that old-private declarations from scopes in the same
> file can now be found by lookups in different scopes (but still only within
> the same file).  It should be quite straightforward for the migrator to
> detect when this has happened and report it as something for the programmer
> to look at.  The proposal causes a small regression in functionality, in
> that there's no longer any way to protect scopes from accesses within the
> file, but (1) it's okay for Swift to be opinionated about file size and (2)
> it seems to me that a workable sub-module proposal should solve that more
> elegantly while simultaneously addressing the concerns of the people who
> dislike acknowledging the existence of files.
>
> John.
>
> -Carl
>
> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your
> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1
> 
> From: Xiaodi Wu <xiaodi...@gmail.com>
> To: Carl Brown1/US/IBM@IBM
> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>,
> swift-evolution <swift-evolution@swift.org>
> Date: 03/25/2017 12:33 AM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> --
>
>
>
> Would it change your opinion on the proposal?
>
>
> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <*carl.bro...@ibm.com*
> <carl.bro...@ibm.com>> wrote:
>
>I would very much like to see your proof that the resultant code is
>unchanged in an arbitrary codebase.
>
>-Carl
>
>Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24,
>2017 at 11:55 PM, Carl Brown1 <*carl.bro...@ibm.com*
><carl.bro...@ibm.com>> wrote: > Maybe this is the core
>
>From: Xiaodi Wu <*xiaodi...@gmail.com* <xiaodi...@gmail.com>>
>To: Carl Brown1/US/IBM@IBM
>Cc: Drew Crawford <*d...@sealedabstract.com* <d...@sealedabstract.com>>,
>Jonathan Hull <*jh...@gbis.com* <jh...@gbis.com>>, swift-evolution <
>*swift-evolution@swift.org* <swift-evolution@swift.org>>
>Date: 03/25/2017 12:01 AM
>Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access
>Levels
>--
>
>
>
>On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <*carl.bro...@ibm.com*
><carl.bro...@ibm.com>> wrote:
>
>My point is that, in rolling back the specific portion of SE-0025,
>case-sensitive find-and-replace will be the trickiest thing in most
>codebases, save those that result in invalid redeclarations. The behavior
>of the resultant code is, unless I'm mistaken, provably unchanged.
>
>
>
>
>
> ___
> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 26 Mar 2017, at 06:54, John McCall via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> Yes, it would change my opinion of it. I wouldn't become a strong supporter 
>> because I don't see any value in it, but a rigorous proof that this proposal 
>> could not possibly introduce regressions to any existing codebases would 
>> change my opinion from "strongly against" to "doesn't matter to me, I'll 
>> stop arguing against it and go get my real work done".
>> 
> Speaking just for myself, this was a key part of why I was attracted to this 
> proposal: it seemed to me to be extremely unlikely to cause regressions in 
> behavior.  Even without any special behavior in the migrator, code will 
> mostly work exactly as before: things that would have been invalid before 
> will become valid, but not the other way around.  The exception is that 
> old-private declarations from scopes in the same file can now be found by 
> lookups in different scopes (but still only within the same file).  It should 
> be quite straightforward for the migrator to detect when this has happened 
> and report it as something for the programmer to look at.  The proposal 
> causes a small regression in functionality, in that there's no longer any way 
> to protect scopes from accesses within the file, but (1) it's okay for Swift 
> to be opinionated about file size and (2) it seems to me that a workable 
> sub-module proposal should solve that more elegantly while simultaneously 
> addressing the concerns of the people who dislike acknowledging the existence 
> of files.

The opinionated flag sometimes, like being Swifty, is being used to swath away 
disagreement, but opinions should be reasonable and pragmatic too... 
opinionated as "you will code this way and you will like it" seems hardly ideal 
too if abused constantly. Programming is a creative endeavour too.

Also, removing a feature that is used and is useful because "maybe" a year or 
more away there could be a feature that may address the concerns of the people 
we are stripping away the current feature from seems quite harsh and unfriendly 
at best... not very logical either.

> 
> John.
>> -Carl
>> 
>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>> > 
>> From: Xiaodi Wu <xiaodi...@gmail.com>
>> To: Carl Brown1/US/IBM@IBM
>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>, 
>> swift-evolution <swift-evolution@swift.org>
>> Date: 03/25/2017 12:33 AM
>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>> 
>> 
>> 
>> 
>> Would it change your opinion on the proposal?
>> 
>> 
>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com> wrote:
>> I would very much like to see your proof that the resultant code is 
>> unchanged in an arbitrary codebase. 
>> 
>> -Carl
>> 
>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 
>> 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote: > Maybe this is the core
>> 
>> From: Xiaodi Wu <xiaodi...@gmail.com>
>> To: Carl Brown1/US/IBM@IBM
>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>, 
>> swift-evolution <swift-evolution@swift.org>
>> Date: 03/25/2017 12:01 AM
>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>> 
>> 
>> 
>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote:
>> My point is that, in rolling back the specific portion of SE-0025, 
>> case-sensitive find-and-replace will be the trickiest thing in most 
>> codebases, save those that result in invalid redeclarations. The behavior of 
>> the resultant code is, unless I'm mistaken, provably unchanged.
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] [Review] SE-0159: Fix Private Access Levels

[Jaden Geller via swift-evolution]

> On Mar 25, 2017, at 10:54 PM, John McCall via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> Yes, it would change my opinion of it. I wouldn't become a strong supporter 
>> because I don't see any value in it, but a rigorous proof that this proposal 
>> could not possibly introduce regressions to any existing codebases would 
>> change my opinion from "strongly against" to "doesn't matter to me, I'll 
>> stop arguing against it and go get my real work done".
>> 
> Speaking just for myself, this was a key part of why I was attracted to this 
> proposal: it seemed to me to be extremely unlikely to cause regressions in 
> behavior.  Even without any special behavior in the migrator, code will 
> mostly work exactly as before: things that would have been invalid before 
> will become valid, but not the other way around.

What about overloads that become ambiguous? I admit this is a fringe case.

> The exception is that old-private declarations from scopes in the same file 
> can now be found by lookups in different scopes (but still only within the 
> same file).  It should be quite straightforward for the migrator to detect 
> when this has happened and report it as something for the programmer to look 
> at.  The proposal causes a small regression in functionality, in that there's 
> no longer any way to protect scopes from accesses within the file, but (1) 
> it's okay for Swift to be opinionated about file size and (2) it seems to me 
> that a workable sub-module proposal should solve that more elegantly while 
> simultaneously addressing the concerns of the people who dislike 
> acknowledging the existence of files.
> 
> John.
>> -Carl
>> 
>> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
>> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>> > 
>> From: Xiaodi Wu <xiaodi...@gmail.com>
>> To: Carl Brown1/US/IBM@IBM
>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>, 
>> swift-evolution <swift-evolution@swift.org>
>> Date: 03/25/2017 12:33 AM
>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>> 
>> 
>> 
>> 
>> Would it change your opinion on the proposal?
>> 
>> 
>> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com> wrote:
>> I would very much like to see your proof that the resultant code is 
>> unchanged in an arbitrary codebase. 
>> 
>> -Carl
>> 
>> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 
>> 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote: > Maybe this is the core
>> 
>> From: Xiaodi Wu <xiaodi...@gmail.com>
>> To: Carl Brown1/US/IBM@IBM
>> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>, 
>> swift-evolution <swift-evolution@swift.org>
>> Date: 03/25/2017 12:01 AM
>> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
>> 
>> 
>> 
>> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote:
>> My point is that, in rolling back the specific portion of SE-0025, 
>> case-sensitive find-and-replace will be the trickiest thing in most 
>> codebases, save those that result in invalid redeclarations. The behavior of 
>> the resultant code is, unless I'm mistaken, provably unchanged.
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] [Review] SE-0159: Fix Private Access Levels

[John McCall via swift-evolution]

> On Mar 25, 2017, at 2:11 AM, Carl Brown1 via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Yes, it would change my opinion of it. I wouldn't become a strong supporter 
> because I don't see any value in it, but a rigorous proof that this proposal 
> could not possibly introduce regressions to any existing codebases would 
> change my opinion from "strongly against" to "doesn't matter to me, I'll stop 
> arguing against it and go get my real work done".
> 
Speaking just for myself, this was a key part of why I was attracted to this 
proposal: it seemed to me to be extremely unlikely to cause regressions in 
behavior.  Even without any special behavior in the migrator, code will mostly 
work exactly as before: things that would have been invalid before will become 
valid, but not the other way around.  The exception is that old-private 
declarations from scopes in the same file can now be found by lookups in 
different scopes (but still only within the same file).  It should be quite 
straightforward for the migrator to detect when this has happened and report it 
as something for the programmer to look at.  The proposal causes a small 
regression in functionality, in that there's no longer any way to protect 
scopes from accesses within the file, but (1) it's okay for Swift to be 
opinionated about file size and (2) it seems to me that a workable sub-module 
proposal should solve that more elegantly while simultaneously addressing the 
concerns of the people who dislike acknowledging the existence of files.

John.
> -Carl
> 
> Xiaodi Wu ---03/25/2017 12:33:55 AM---Would it change your 
> opinion on the proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
>  
> From: Xiaodi Wu <xiaodi...@gmail.com>
> To: Carl Brown1/US/IBM@IBM
> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>, 
> swift-evolution <swift-evolution@swift.org>
> Date: 03/25/2017 12:33 AM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> 
> 
> 
> 
> Would it change your opinion on the proposal?
> 
> 
> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com 
> <mailto:carl.bro...@ibm.com>> wrote:
> I would very much like to see your proof that the resultant code is unchanged 
> in an arbitrary codebase. 
> 
> -Carl
> 
> Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 
> 11:55 PM, Carl Brown1 <carl.bro...@ibm.com <mailto:carl.bro...@ibm.com>> 
> wrote: > Maybe this is the core
> 
> From: Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>>
> To: Carl Brown1/US/IBM@IBM
> Cc: Drew Crawford <d...@sealedabstract.com <mailto:d...@sealedabstract.com>>, 
> Jonathan Hull <jh...@gbis.com <mailto:jh...@gbis.com>>, swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
> Date: 03/25/2017 12:01 AM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> 
> 
> 
> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com 
> <mailto:carl.bro...@ibm.com>> wrote:
> My point is that, in rolling back the specific portion of SE-0025, 
> case-sensitive find-and-replace will be the trickiest thing in most 
> codebases, save those that result in invalid redeclarations. The behavior of 
> the resultant code is, unless I'm mistaken, provably unchanged.
> 
> 
> 
> 
> 
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon via swift-evolution]

> On Mar 25, 2017, at 6:46 AM, Jonathan Hull  wrote:
> 
>> On Mar 25, 2017, at 6:39 AM, Brent Royal-Gordon > > wrote:
>> 
>>> On Mar 25, 2017, at 12:32 AM, Jonathan Hull via swift-evolution 
>>> > wrote:
>>> 
>>> • Remove ‘private’ keyword
>>> • Rename ‘fileprivate’ to ‘local’ with the understanding it now means 
>>> local to the containing submodule
>>> • If no submodule is declared, the file is its own anonymous submodule
>> 
>> 
>> This is kind of not the place for a full submodule discussion, but: I don't 
>> think a submodule system which doesn't have a unit of encapsulation smaller 
>> than the entire submodule is going to work.

> 
> I am confused. Half of my email was about how to encapsulate smaller than the 
> entire submodule using ‘module { }'

Yes, but then within a nested module, you can't make something visible only to 
the surrounding module; you can only make it too visible (by exposing it to 
`internal`) or not visible enough (by keeping it `private`). You can't even 
create a symbol in the outer scope and access the inner scope's symbol there, 
because it won't be able to access it.

This is the problem with all access levels based on arbitrary, nestable scopes: 
in any given place you can't address many of the scopes, so if need a 
visibility level other than the exact current scope, you have to make it much 
more widely visible than you'd prefer.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

I am confused. Half of my email was about how to encapsulate smaller than the 
entire submodule using ‘module { }'

> On Mar 25, 2017, at 6:39 AM, Brent Royal-Gordon  
> wrote:
> 
>> On Mar 25, 2017, at 12:32 AM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>>  • Remove ‘private’ keyword
>>  • Rename ‘fileprivate’ to ‘local’ with the understanding it now means 
>> local to the containing submodule
>>  • If no submodule is declared, the file is its own anonymous submodule
> 
> 
> This is kind of not the place for a full submodule discussion, but: I don't 
> think a submodule system which doesn't have a unit of encapsulation smaller 
> than the entire submodule is going to work.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Brent Royal-Gordon via swift-evolution]

> On Mar 25, 2017, at 12:32 AM, Jonathan Hull via swift-evolution 
>  wrote:
> 
>   • Remove ‘private’ keyword
>   • Rename ‘fileprivate’ to ‘local’ with the understanding it now means 
> local to the containing submodule
>   • If no submodule is declared, the file is its own anonymous submodule


This is kind of not the place for a full submodule discussion, but: I don't 
think a submodule system which doesn't have a unit of encapsulation smaller 
than the entire submodule is going to work.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[ark dan via swift-evolution]

• What is your evaluation of the proposal?
+1

• Is the problem being addressed significant enough to warrant a change to 
Swift?

Yes. For some strange reason, i can’t bring myself to write `fileprivate` 
instead of `private` by default - if i don’t specifically think of it, i end up 
with privates everywhere, and then have to go back and change to `fileprivate`. 
At times, it seems a bit annoying.

• Does this proposal fit well with the feel and direction of Swift?

Oh yes. fileprivate is too long a word for access level that i pretty much use 
as a default; and definitely not intuitive.

I write as much framework code, as application logic. Since Swift 3 i don’t 
remember many cases where i had to use `private`. I do, however, have many 
`private` members in my code - solely because `private` is way more intuitive 
to write.

~99% of privates in my code are there by mistake - but thats what i end up 
with. That means, there is no need for a mixed code like that 99% of the time:

private(set) var iosAudio: CMSampleBuffer?
private(set) var iosVideo: CMSampleBuffer?
fileprivate(set) var mic: CMSampleBuffer?
fileprivate(set) var serialNumber: String
fileprivate(set) var name: String

It also means, the 1% where i want to use `private`, the readers/users of my 
code may think it's a mistake too.

My point of view, the number of times i mean "this variable or function can 
only be accessed from within tis file" dwarfs the number when i mean "it can 
only be accessed by subclasses". They don't even compare.

If enough people need access based on class hierarchy, we should pick a keyword 
specifically for that - like "classprivate" if you will. But private within the 
file simply makes more sense.

• If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to
those?
N/A

• How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

I have strong opinion based on how i use Swift, which i love deep from the 
heart. 

Thanks David & Doug for giving hope this may actually be reverted.

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

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Tony Arnold via swift-evolution]

Hi Doug (and list),


> What is your evaluation of the proposal?

-1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

No, I also think it is not the _correct_ answer to the actual issues with 
access control in Swift right now.


> Does this proposal fit well with the feel and direction of Swift?

With the feel of the proposal, yes. Simplicity is good, less is more and I love 
that Swift seems to value succinctness where it makes sense.

Does the proposal fit with the direction? 

I would have to say no. 

Using files as an axis of access control seems wrong to me - ultimately, people 
seem to be using `fileprivate` as a workaround for the lack of an access level 
that allows extensions in other files to see members/functions (and some for 
keeping everything in one file - which seems like quite bad practice to me). 
`private` (as it is defined right now in Swift 3) actually seems to me to be 
logical to keep in light of discussions around future work toward submodules.

My considered feeling is that if we’re not going to solve the issue of access 
control holistically - whether by adding other access levels, or by something 
else like submodules — the change being proposed in SE-0159 seems like 
shuffling deck chairs on the Titanic.


> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

Not applicable. My use of other languages is old, out-of-date and not relevant 
to Swift or this situation. I bring only my Objective-C/Cocoa and Swift 
knowledge/experience with me this time.


> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

A fair bit of reading both of the posts to the list, some investigation of 
features in other languages, then a lot of consternation around actually 
participating in this conversation. 


thanks,


Tony




 --
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

Ok, I have been thinking all day if I can come up with of a design which would 
still provide scoped private (and keep file-based private) without causing the 
current confusion.  Here is the best I have so far.  I warn you it trades one 
weirdness for another, but at least the new weirdness is progressively 
disclosed, so it should be less problematic:

Swift 4
• Depreciate ‘private’ with a warning that it will be removed in Swift 5

Swift 5
• Remove ‘private’ keyword
• Rename ‘fileprivate’ to ‘local’ with the understanding it now means 
local to the containing submodule
• If no submodule is declared, the file is its own anonymous submodule
• A group of files can declare themselves a submodule by each saying 
‘module name’ with the same name somewhere in the file (only one declaration is 
allowed per file)
• Within the file ‘module { }’ can declare an anonymous module (within 
the braces) nested inside the current module
• For fun: Stored properties are allowed to be declared within 
extensions in a type’s containing submodule

That ‘module { }' part is the new weirdness, but it should cause less confusion 
overall.  A few points:
• They could be nested as deep as you like
• It needs to be anonymous so you aren’t tempted to connect it with 
other submodules (in other files)
• You could recreate the current behavior of private by wrapping your 
type in a module block
• …or you could wrap that block around a type and it’s friend
• …or you could wrap only part of your type (crucial if you want both 
private and fileprivate behavior in the same type)
• Internal, public, and open would retain their current meanings


Thoughts on this approach?  It isn’t my first choice, but it is much better 
than what we have now.  

It should let you do everything you do now and then some (but with the extra 
complexity tucked away for the most part).  I.e. If you don’t know what 
submodules are, the system appears structurally the same as Swift 2.  You can 
learn about submodules without learning about ‘module {}’.  In exchange, scoped 
private becomes more complex… but you also have finer control over the scope 
(it can cover only part of a large type or two friend types).

Thanks,
Jon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Sat, Mar 25, 2017 at 1:11 AM, Carl Brown1 <carl.bro...@ibm.com> wrote:

> Yes, it would change my opinion of it. I wouldn't become a strong
> supporter because I don't see any value in it, but a rigorous proof that
> this proposal could not possibly introduce regressions to any existing
> codebases would change my opinion from "strongly against" to "doesn't
> matter to me, I'll stop arguing against it and go get my real work done".
>

Well, that's promising, I guess? I think it's entirely reasonable to want a
migration path that can demonstrably preserve the behavior of existing
codebases.

For most use sites, it would be no more than find-and-replace; a more
sophisticated process will be required for scenarios where a private
declaration uses a name identical to something called elsewhere in the
file--in the worst case, a renaming will be required, such as in a case
like this:

```

func f() -> String {

  return "A"

}


struct S {

  static func g() -> String {

return f()

  }

}


extension S {

  private static func f() -> String {

return "B"

  }

}


S.g()
```

This will require some compiler smarts. And I think a successful proposal
would have to provide solid proof that all such scenarios are covered. I'll
think about this over the weekend.

>
>
> -Carl
>
> [image: Inactive hide details for Xiaodi Wu ---03/25/2017 12:33:55
> AM---Would it change your opinion on the proposal? On Sat, Mar 25, 2]Xiaodi
> Wu ---03/25/2017 12:33:55 AM---Would it change your opinion on the
> proposal? On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 
> From: Xiaodi Wu <xiaodi...@gmail.com>
> To: Carl Brown1/US/IBM@IBM
> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>,
> swift-evolution <swift-evolution@swift.org>
> Date: 03/25/2017 12:33 AM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> --
>
>
>
> Would it change your opinion on the proposal?
>
>
> On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <*carl.bro...@ibm.com*
> <carl.bro...@ibm.com>> wrote:
>
>I would very much like to see your proof that the resultant code is
>unchanged in an arbitrary codebase.
>
>-Carl
>
>[image: Inactive hide details for Xiaodi Wu ---03/25/2017 12:01:26
>AM---On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <Carl.Brown1@ibm.]Xiaodi
>Wu ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 11:55 PM, Carl
>Brown1 <*carl.bro...@ibm.com* <carl.bro...@ibm.com>> wrote: > Maybe
>this is the core
>
>From: Xiaodi Wu <*xiaodi...@gmail.com* <xiaodi...@gmail.com>>
>To: Carl Brown1/US/IBM@IBM
>Cc: Drew Crawford <*d...@sealedabstract.com* <d...@sealedabstract.com>>,
>Jonathan Hull <*jh...@gbis.com* <jh...@gbis.com>>, swift-evolution <
>*swift-evolution@swift.org* <swift-evolution@swift.org>>
>Date: 03/25/2017 12:01 AM
>Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access
>Levels
>--
>
>
>
>On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <*carl.bro...@ibm.com*
><carl.bro...@ibm.com>> wrote:
>
>My point is that, in rolling back the specific portion of SE-0025,
>case-sensitive find-and-replace will be the trickiest thing in most
>codebases, save those that result in invalid redeclarations. The behavior
>of the resultant code is, unless I'm mistaken, provably unchanged.
>
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Carl Brown1 via swift-evolution]

Yes, it would change my opinion of it.  I wouldn't become a strong
supporter because I don't see any value in it, but a rigorous proof that
this proposal could not possibly introduce regressions to any existing
codebases would change my opinion from "strongly against" to "doesn't
matter to me, I'll stop arguing against it and go get my real work done".

-Carl



From:   Xiaodi Wu <xiaodi...@gmail.com>
To: Carl Brown1/US/IBM@IBM
Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull
<jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
Date:   03/25/2017 12:33 AM
Subject:        Re: [swift-evolution] [Review] SE-0159: Fix Private Access
Levels



Would it change your opinion on the proposal?


On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com> wrote:
  I would very much like to see your proof that the resultant code is
  unchanged in an arbitrary codebase.

  -Carl

  Inactive hide details for Xiaodi Wu ---03/25/2017 12:01:26 AM---On Fri,
  Mar 24, 2017 at 11:55 PM, Carl Brown1 <Carl.Brown1@ibm.Xiaodi Wu
  ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1
  <carl.bro...@ibm.com> wrote: > Maybe this is the core

  From: Xiaodi Wu <xiaodi...@gmail.com>
  To: Carl Brown1/US/IBM@IBM
  Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <
  jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
  Date: 03/25/2017 12:01 AM
  Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access
  Levels



  On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com>
  wrote:


  My point is that, in rolling back the specific portion of SE-0025,
  case-sensitive find-and-replace will be the trickiest thing in most
  codebases, save those that result in invalid redeclarations. The behavior
  of the resultant code is, unless I'm mistaken, provably unchanged.











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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Sat, Mar 25, 2017 at 12:26 AM, Drew Crawford 
wrote:

>
>
>
> On March 24, 2017 at 11:20:59 PM, Jonathan Hull (jh...@gbis.com) wrote:
>
> You were the one who said redundancy was a *goal* of swift, which it is
> not.
>
> You misunderstand.  I'm arguing that the design of Swift is to have
> concept pairs – private/fileprivate, class/struct, let/var – in which one
> element of the pair is a superset of the other.  That is: we could convert
> a let/var program to use only var, we could convert a private/fileprivate
> program to use only fileprivate, etc., and yet we stubbornly persist to
> have all these keywords.
>
Again, this is deliberately ignoring the points made above. As we discussed
with dispatch models, speed is a key goal of Swift, and `let` vs `var`
offers optimization opportunities for the compiler. I've never heard of
anyone proposing that the design of Swift is based around concept pairs.
Nor are those you listed pairs of anything: `private` and `fileprivate` are
two of five access levels; there are not only classes and structs but also
enums and tuples; `let` and `var` will shortly be joined by `inout` and
`shared`, etc. Neither two, nor four, nor five are magic numbers. The
question is, how many of whatever it is we're considering hold their own
weight. The argument here is that new `private` does not.

This property has been labeled "redundancy" by people who dislike it.  I'm
> saying that whatever unkind name we decide to call it, it's a Swiftism, and
> we embraced it a long time ago.
>
What is "this property" that you claim to be a "Swiftism"?

Perhaps I just do not understand your argument, but it seems to be
>
> In your examples above, Swift is projecting a system image which is much
> simpler than the underlying concepts... For access controls, the user is
> being presented with the full complexity of that choice directly.
>
> This seems simply inaccurate to me.  For example, I am the top search
> result for "swift struct or class" and my explanation is 27 pages.
> Admittedly I am an insufferably longwinded writer who can't find the delete
> key, but for whatever reason Google seems to think my explanation is
> helpful to people struggling with that topic.
>
So indeed, Swift presents an apparently simple distinction with some very
complex underlying implications, since an explanation of it all can fill 27
pages.

While it is true that access control presents users the "the full
> complexity of that choice directly", this is because the choice is not
> actually complex.  One keyword is visible to a file and the other to a
> scope.  I could not produce 27 pages on that topic.
>
I am quite certain that we have filled many more than 27 pages on that
topic here. If you want to collate it into a didactic format you can start
with the delightful explanation of why ```private extension Foo { }```
works the way it does.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

Would it change your opinion on the proposal?


On Sat, Mar 25, 2017 at 12:10 AM, Carl Brown1 <carl.bro...@ibm.com> wrote:

> I would very much like to see your proof that the resultant code is
> unchanged in an arbitrary codebase.
>
> -Carl
>
> [image: Inactive hide details for Xiaodi Wu ---03/25/2017 12:01:26 AM---On
> Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <Carl.Brown1@ibm.]Xiaodi Wu
> ---03/25/2017 12:01:26 AM---On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <
> carl.bro...@ibm.com> wrote: > Maybe this is the core
>
> From: Xiaodi Wu <xiaodi...@gmail.com>
> To: Carl Brown1/US/IBM@IBM
> Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com>,
> swift-evolution <swift-evolution@swift.org>
> Date: 03/25/2017 12:01 AM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> --
>
>
>
> On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <*carl.bro...@ibm.com*
> <carl.bro...@ibm.com>> wrote:
>
> My point is that, in rolling back the specific portion of SE-0025,
> case-sensitive find-and-replace will be the trickiest thing in most
> codebases, save those that result in invalid redeclarations. The behavior
> of the resultant code is, unless I'm mistaken, provably unchanged.
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 11:20:59 PM, Jonathan Hull (jh...@gbis.com) wrote:

You were the one who said redundancy was a *goal* of swift, which it is not.
You misunderstand.  I'm arguing that the design of Swift is to have concept 
pairs – private/fileprivate, class/struct, let/var – in which one element of 
the pair is a superset of the other.  That is: we could convert a let/var 
program to use only var, we could convert a private/fileprivate program to use 
only fileprivate, etc., and yet we stubbornly persist to have all these 
keywords.

This property has been labeled "redundancy" by people who dislike it.  I'm 
saying that whatever unkind name we decide to call it, it's a Swiftism, and we 
embraced it a long time ago.

Perhaps I just do not understand your argument, but it seems to be

In your examples above, Swift is projecting a system image which is much 
simpler than the underlying concepts... For access controls, the user is being 
presented with the full complexity of that choice directly.
This seems simply inaccurate to me.  For example, I am the top search result 
for "swift struct or class" and my explanation is 27 pages.  Admittedly I am an 
insufferably longwinded writer who can't find the delete key, but for whatever 
reason Google seems to think my explanation is helpful to people struggling 
with that topic.

While it is true that access control presents users the "the full complexity of 
that choice directly", this is because the choice is not actually complex.  One 
keyword is visible to a file and the other to a scope.  I could not produce 27 
pages on that topic.



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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Carl Brown1 via swift-evolution]

I would very much like to see your proof that the resultant code is
unchanged in an arbitrary codebase.

-Carl



From:   Xiaodi Wu <xiaodi...@gmail.com>
To: Carl Brown1/US/IBM@IBM
Cc: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull
<jh...@gbis.com>, swift-evolution <swift-evolution@swift.org>
Date:   03/25/2017 12:01 AM
Subject:    Re: [swift-evolution] [Review] SE-0159: Fix Private Access
Levels



On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote:


My point is that, in rolling back the specific portion of SE-0025,
case-sensitive find-and-replace will be the trickiest thing in most
codebases, save those that result in invalid redeclarations. The behavior
of the resultant code is, unless I'm mistaken, provably unchanged.









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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 11:55 PM, Carl Brown1 <carl.bro...@ibm.com> wrote:

> Maybe this is the core of this whole issue. In my experience, the very
> easiest part of the software development process is getting it to compile.
> The *real effort* doesn't even start until after that's completed.
>
> If I thought that "case-sensitive find-and-relace" was "the tricky thing"
> in developing software, and all I had to care about was avoiding "invalid
> redeclarations anywhere" then this proposal might seem like a good idea to
> me, too.
>
My point is that, in rolling back the specific portion of SE-0025,
case-sensitive find-and-replace will be the trickiest thing in most
codebases, save those that result in invalid redeclarations. The behavior
of the resultant code is, unless I'm mistaken, provably unchanged. This in
itself bolsters the case that the distinction between `fileprivate` and
`private` did not really carry its own weight.

Indeed, if I thought that there would be an unknowable amount of effort
required to migrate code, then I would be more hesitant about rolling back
SE-0025. That said, I'm curious as to how your argument would not apply to
literally every single source-breaking change.

>
> -Carl
>
>
> [image: Inactive hide details for Xiaodi Wu via swift-evolution
> ---03/24/2017 11:10:54 PM---On Fri, Mar 24, 2017 at 10:47 PM, Xiaodi Wu]Xiaodi
> Wu via swift-evolution ---03/24/2017 11:10:54 PM---On Fri, Mar 24, 2017 at
> 10:47 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > As Chris has said in
> the
>
> From: Xiaodi Wu via swift-evolution <swift-evolution@swift.org>
> To: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com
> >
> Cc: swift-evolution <swift-evolution@swift.org>
> Date: 03/24/2017 11:10 PM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> Sent by: swift-evolution-boun...@swift.org
> --
>
>
> On Fri, Mar 24, 2017 at 10:47 PM, Xiaodi Wu <*xiaodi...@gmail.com*
> <xiaodi...@gmail.com>> wrote:
>
> Update: with the caveat that corelibs-foundation tests are incomplete, it
> took me about 15 mins to migrate all uses of private to fileprivate. The
> tricky thing is that one has to do case-sensitive find-and-replace, and to
> replace all instances of "filefileprivate" in a second round. It does not
> appear that corelibs-foundation actually uses new `private` in a way that
> migrating to `fileprivate` results in invalid redeclarations anywhere.
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Carl Brown1 via swift-evolution]

Maybe this is the core of this whole issue. In my experience, the very
easiest part of the software development process is getting it to compile.
The *real effort* doesn't even start until after that's completed.

If I thought that "case-sensitive find-and-relace" was "the tricky thing"
in developing software, and all I had to care about was avoiding "invalid
redeclarations anywhere" then this proposal might seem like a good idea to
me, too.

-Carl



From:   Xiaodi Wu via swift-evolution <swift-evolution@swift.org>
To: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull
<jh...@gbis.com>
Cc: swift-evolution <swift-evolution@swift.org>
Date:   03/24/2017 11:10 PM
Subject:    Re: [swift-evolution] [Review] SE-0159: Fix Private Access
Levels
Sent by:swift-evolution-boun...@swift.org


On Fri, Mar 24, 2017 at 10:47 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:

Update: with the caveat that corelibs-foundation tests are incomplete, it
took me about 15 mins to migrate all uses of private to fileprivate. The
tricky thing is that one has to do case-sensitive find-and-replace, and to
replace all instances of "filefileprivate" in a second round. It does not
appear that corelibs-foundation actually uses new `private` in a way that
migrating to `fileprivate` results in invalid redeclarations anywhere.


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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 11:36 PM, Carl Brown1 <carl.bro...@ibm.com> wrote:

> First off, SE-0159 does not, in my opinion and the opinions of many people
> on this list, present a superior experience for the end user.
>
That is precisely the topic of this review process.


> It removes a feature that many people use and will create more confusion
> by rendering many online tutorials and answered questions incorrect.
>
> Furthermore, the assertion that there is a "knowable" amount of effort
> required to "roll back" corelibs-foundation is laughable. "Look, it
> compiles" is nowhere near the level of rigor required for a code base that
> has as much code depending on it as Foundation has. Remember that the
> standard for corelibs-foundation is not even "it works." The standard is:
> "behaves the same way on Linux that Foundation does on Darwin." If
> something is accessible on Linux but not on Darwin, that's a bug, and needs
> to get fixed. Testing, finding, and fixing the regressions the "roll back"
> will cause is what constitutes the bulk of the effort, and that amount of
> effort cannot possibly be accurately estimated.
>
Agreed on the standard, but neither here nor there. First, `private` vs.
`fileprivate` by definition cannot change the external API. Second, the
migration from Swift 2 to 3 was an essentially equal and opposite effort,
and in those portions of the code, restoring the original version is just
as likely to fix regressions as migrating newer code is to introduce new
ones. Third, any broadening of access from `private` to `fileprivate` that
does not result in an invalid redeclaration (always flagged by the
compiler) is, unless I'm mistaken, unable to change the behavior of
otherwise unmodified code.


>
> -Carl
>
>
> [image: Inactive hide details for Xiaodi Wu via swift-evolution
> ---03/24/2017 10:48:09 PM---As Chris has said in the past, the core tea]Xiaodi
> Wu via swift-evolution ---03/24/2017 10:48:09 PM---As Chris has said in the
> past, the core team is willing to endure a substantial amount of implementa
>
> From: Xiaodi Wu via swift-evolution <swift-evolution@swift.org>
> To: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull <jh...@gbis.com
> >
> Cc: swift-evolution <swift-evolution@swift.org>
> Date: 03/24/2017 10:48 PM
> Subject: Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels
> Sent by: swift-evolution-boun...@swift.org
> --
>
>
>
> As Chris has said in the past, the core team is willing to endure a
> substantial amount of implementation pain to present a superior experience
> for the end user. In any case, I expect that the work needed to roll back
> SE-0025 in the core libraries will likely be comparable if not less than
> the remaining ongoing work needed in the compiler to make SE-0025 work
> fully. Certainly, hundreds of hours would not be required to roll back
> corelibs-foundation alone. The exact effort required is knowable, too, as
> one can fork and migrate all uses of private to fileprivate right now and
> see how long it takes.
> On Fri, Mar 24, 2017 at 22:38 Drew Crawford via swift-evolution <
> *swift-evolution@swift.org* <swift-evolution@swift.org>> wrote:
>
>
>
>On March 24, 2017 at 10:21:17 PM, Jonathan Hull (*jh...@gbis.com*
><jh...@gbis.com>) wrote:
>This is exactly the problem. Both for access controls and dispatch.
>
>How would you respond to clattner's *position piece*
>
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html>
>  on
>this?  He disputes this point directly:
>Swift is another case of a hybrid model: its semantics provide
>  predictability between obviously static (structs, enums, and global 
> funcs)
>  and obviously dynamic (classes, protocols, and closures) constructs. 
>  A
>  focus of Swift (like Java and Javascript) is to provide an apparently
>  simple programming model.  However, Swift also intentionally 
> "cheats" in
>  its global design by mixing in a few tricks to make the dynamic 
> parts of
>  the language optimizable by a static compiler in many common cases...
>  The upshot of this is that Swift isn’t squarely in either of the
>  static or dynamic camps: it aims to provide a very predictable 
> performance
>  model (someone writing a bootloader or firmware can stick to using 
> Swift
>  structs and have a simple guarantee of no dynamic overhead or runtime
>  dependence) while also providing an expressive and clean high level
>  programming model - simplifying learning

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Carl Brown1 via swift-evolution]

First off, SE-0159 does not, in my opinion and  the opinions of many people
on this list, present a superior experience for the end user.  It removes a
feature that many people use and will create more confusion by rendering
many online tutorials and answered questions incorrect.

Furthermore, the assertion that there is a "knowable" amount of effort
required to "roll back" corelibs-foundation is laughable.  "Look, it
compiles" is nowhere near the level of rigor required for a code base that
has as much code depending on it as Foundation has. Remember that the
standard for corelibs-foundation is not even "it works." The standard is:
"behaves the same way on Linux that Foundation does on Darwin."  If
something is accessible on Linux but not on Darwin, that's a bug, and needs
to get fixed.  Testing, finding, and fixing the regressions the "roll back"
will cause is what constitutes the bulk of the effort, and that amount of
effort cannot possibly be accurately estimated.

-Carl




From:   Xiaodi Wu via swift-evolution <swift-evolution@swift.org>
To: Drew Crawford <d...@sealedabstract.com>, Jonathan Hull
<jh...@gbis.com>
Cc: swift-evolution <swift-evolution@swift.org>
Date:   03/24/2017 10:48 PM
Subject:    Re: [swift-evolution] [Review] SE-0159: Fix Private Access
Levels
Sent by:swift-evolution-boun...@swift.org



As Chris has said in the past, the core team is willing to endure a
substantial amount of implementation pain to present a superior experience
for the end user. In any case, I expect that the work needed to roll back
SE-0025 in the core libraries will likely be comparable if not less than
the remaining ongoing work needed in the compiler to make SE-0025 work
fully. Certainly, hundreds of hours would not be required to roll back
corelibs-foundation alone. The exact effort required is knowable, too, as
one can fork and migrate all uses of private to fileprivate right now and
see how long it takes.
On Fri, Mar 24, 2017 at 22:38 Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:





  On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@gbis.com) wrote:


This is exactly the problem. Both for access controls and dispatch.


  How would you respond to clattner's position piece on this?  He disputes
  this point directly:

Swift is another case of a hybrid model: its semantics provide
predictability between obviously static (structs, enums, and global
funcs) and obviously dynamic (classes, protocols, and closures)
constructs.  A focus of Swift (like Java and Javascript) is to
provide an apparently simple programming model.  However, Swift
also intentionally "cheats" in its global design by mixing in a few
tricks to make the dynamic parts of the language optimizable by a
static compiler in many common cases...
The upshot of this is that Swift isn’t squarely in either of the
static or dynamic camps: it aims to provide a very predictable
performance model (someone writing a bootloader or firmware can
stick to using Swift structs and have a simple guarantee of no
dynamic overhead or runtime dependence) while also providing an
expressive and clean high level programming model - simplifying
learning and the common case where programmers don’t care to count
cycles.


Is it?  Can you point to an instance where a member of the core
team said they are aiming for “plenty of overlap”?


  See above


Honestly, most of your examples could just be split into multiple
files.


  Specific arguments were advanced in those examples that they cannot.  Can
  you refute them?


You are conflating effort by the swift design and implementation
community with your personal effort around migration.


  No, I am referencing a Swift@IBM developer who reported that


the open-source version of Foundation still has a long way to go to
get the level of quality of the existing Objective-C frameworks,
and we already have enough work to do without having to go make a
bunch of arbitrary changes and risk a bunch of regressions because
someone doesn't like a keyword... Accepting this proposal would
waste hundreds of person-hours of work...
  ___
  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] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 11:09 PM, Drew Crawford 
wrote:

>
>
>
> On March 24, 2017 at 10:28:43 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> I'm not sure where you're reading that Chris thinks the current design
> reaches the stated aims to his satisfaction.
>
> I'm pretty sure it's a fair assumption that when he introduces the
> static/dynamic system to illustrate the design goals of Swift, he means
> those goals can be seen in that feature to some significant extent.
>
> "We intentionally want Swift to have a common 'center of gravity' and be
> an 'opinionated' language, rather than fall to the 'design by committee'
> approach that leads to a watered-down design."  This is diametrically
> opposite to "shipping a full toolbox with plenty of overlap."
>
> Chris has elaborated on this elsewhere
> :
>
> Another thing to keep in mind is that Swift is opinionated, I guess is the
> way to say it. It really does encourage you to do the right thing where it
> can. For example, if you use var for everything, the Swift compiler
> [1:21:30] will say, hey, you marked this as a var but it could be a let,
> and let me fix it for you. That's just its subtle way of encouraging you to
> use immutable values, which is a very small thing, but it's just pushing
> you in the way that it thinks leads to a better code. Immutability for a
> local variable doesn't matter that much except that it communicates
> something more to the person who has to read and maintain your code.
>
> I think that Swift really does [1:22:00] encourage you down the right
> lines in some ways. But on the other hand, in other places where you're
> saying, "Should something be a class or a struct?”, the trade-offs are more
> nuanced and it's a harder thing, and the Swift compiler can't just know
> what problem it is that you want to solve, so it can't help you with that.
>
> `let` and `var` are "redundant" in the same way as private/fileprivate;
> one can effectively replace the other.  Far from advocating we should
> eliminate the redundant keyword, he argues the compiler should encourage
> it, because "Swift is an opinionated language" and an argument to the
> principle of least power.  The analogous idea would be if the compiler
> offered a fixit to change "fileprivate" to "private" where legal.
>
This was already brought up on the list. There was some consensus that it's
inconsistent with the changes in SE-0025 because that proposal specifically
allows higher access levels to be used even when the effective visibility
is more limited. A fix-it such as you suggest would make a one-off
exception to that rule for `fileprivate`.

Moreover, it was thought that the predominant scenario in which
`fileprivate` is used where `private` is sufficient was due to Swift 2-to-3
migrator artifact. If so, it's overkill to carve out a _permanent_
exception that complicates the rules for using access modifiers instead of
improving the migrator. On the other hand, if the predominant scenario in
which this fix-it would be triggered is _user_ error, then we've got a
pretty good sign that having both `fileprivate` and `private` is a
pervasive problem for users.

> Actually, that would be an interesting proposal, especially since some
> believe private/fileprivate is hard to learn.
>
> But "Swift is an opinionated language" is not a battlecry for eliminating
> "redundant" keywords, it is an exhortation to use them correctly.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 11:09 PM, Drew Crawford 
wrote:

>
>
>
> On March 24, 2017 at 10:28:43 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> I'm not sure where you're reading that Chris thinks the current design
> reaches the stated aims to his satisfaction.
>
> I'm pretty sure it's a fair assumption that when he introduces the
> static/dynamic system to illustrate the design goals of Swift,
>

First, Chris neither initiated the static/dynamic distinction in that
discussion, nor was the discussion about Swift design goals in general.
Rather, he was explaining the design goals specifically behind the current
hybrid model for dispatch in a thread about dispatch (the thread was titled
"universal dynamic dispatch for method calls"), and I see no claim about
how well the design as implemented in Swift lines up with the goals.

he means those goals can be seen in that feature to some significant extent.
>
> "We intentionally want Swift to have a common 'center of gravity' and be
> an 'opinionated' language, rather than fall to the 'design by committee'
> approach that leads to a watered-down design."  This is diametrically
> opposite to "shipping a full toolbox with plenty of overlap."
>
> Chris has elaborated on this elsewhere
> :
>
Another thing to keep in mind is that Swift is opinionated, I guess is the
> way to say it. It really does encourage you to do the right thing where it
> can. For example, if you use var for everything, the Swift compiler
> [1:21:30] will say, hey, you marked this as a var but it could be a let,
> and let me fix it for you. That's just its subtle way of encouraging you to
> use immutable values, which is a very small thing, but it's just pushing
> you in the way that it thinks leads to a better code. Immutability for a
> local variable doesn't matter that much except that it communicates
> something more to the person who has to read and maintain your code.
>
> I think that Swift really does [1:22:00] encourage you down the right
> lines in some ways. But on the other hand, in other places where you're
> saying, "Should something be a class or a struct?”, the trade-offs are more
> nuanced and it's a harder thing, and the Swift compiler can't just know
> what problem it is that you want to solve, so it can't help you with that.
>
> `let` and `var` are "redundant" in the same way as private/fileprivate;
> one can effectively replace the other.
>

There is more than one way in which Swift can be opinionated. In the
excerpt I provided, Chris was speaking about the evolution process. The
very next sentence after "..watered-down design" is: "This means that
decisions are really all shades of gray and cannot be specified or
predicted by algorithm." In some cases, the shades of gray come down in
favor of keeping two things; in others, it does not. Arguments must be
weighed in the context of specific design goals. Chris specifically says
that there is no generalizable algorithm, and one cannot point to `let` and
`var` and say that access levels should be this way or that.

Far from advocating we should eliminate the redundant keyword, he argues
> the compiler should encourage it, because "Swift is an opinionated
> language" and an argument to the principle of least power.  The analogous
> idea would be if the compiler offered a fixit to change "fileprivate" to
> "private" where legal.  Actually, that would be an interesting proposal,
> especially since some believe private/fileprivate is hard to learn.
>
> But "Swift is an opinionated language" is not a battlecry for eliminating
> "redundant" keywords, it is an exhortation to use them correctly.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

You seem to be completely missing basically every point I have made.  You were 
the one who said redundancy was a *goal* of swift, which it is not.

I have explained the actual issues with the current design of access controls 
in earlier posts (as well as various mitigation strategies). They had nothing 
to do with redundancy.


> On Mar 24, 2017, at 9:09 PM, Drew Crawford  wrote:
> On March 24, 2017 at 10:28:43 PM, Xiaodi Wu (xiaodi...@gmail.com 
> ) wrote:
> 
>> I'm not sure where you're reading that Chris thinks the current design 
>> reaches the stated aims to his satisfaction.
> 
> I'm pretty sure it's a fair assumption that when he introduces the 
> static/dynamic system to illustrate the design goals of Swift, he means those 
> goals can be seen in that feature to some significant extent.
> 
>> "We intentionally want Swift to have a common 'center of gravity' and be an 
>> 'opinionated' language, rather than fall to the 'design by committee' 
>> approach that leads to a watered-down design."  This is diametrically 
>> opposite to "shipping a full toolbox with plenty of overlap."
> 
> Chris has elaborated on this elsewhere 
> :
> 
>> Another thing to keep in mind is that Swift is opinionated, I guess is the 
>> way to say it. It really does encourage you to do the right thing where it 
>> can. For example, if you use var for everything, the Swift compiler 
>> [1:21:30] will say, hey, you marked this as a var but it could be a let, and 
>> let me fix it for you. That's just its subtle way of encouraging you to use 
>> immutable values, which is a very small thing, but it's just pushing you in 
>> the way that it thinks leads to a better code. Immutability for a local 
>> variable doesn't matter that much except that it communicates something more 
>> to the person who has to read and maintain your code.
>> 
>> I think that Swift really does [1:22:00] encourage you down the right lines 
>> in some ways. But on the other hand, in other places where you're saying, 
>> "Should something be a class or a struct?”, the trade-offs are more nuanced 
>> and it's a harder thing, and the Swift compiler can't just know what problem 
>> it is that you want to solve, so it can't help you with that.
>> 
> 
> `let` and `var` are "redundant" in the same way as private/fileprivate; one 
> can effectively replace the other.  Far from advocating we should eliminate 
> the redundant keyword, he argues the compiler should encourage it, because 
> "Swift is an opinionated language" and an argument to the principle of least 
> power.  The analogous idea would be if the compiler offered a fixit to change 
> "fileprivate" to "private" where legal.  Actually, that would be an 
> interesting proposal, especially since some believe private/fileprivate is 
> hard to learn.
> 
> But "Swift is an opinionated language" is not a battlecry for eliminating 
> "redundant" keywords, it is an exhortation to use them correctly.
> 

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 10:47 PM, Xiaodi Wu  wrote:

> As Chris has said in the past, the core team is willing to endure a
> substantial amount of implementation pain to present a superior experience
> for the end user. In any case, I expect that the work needed to roll back
> SE-0025 in the core libraries will likely be comparable if not less than
> the remaining ongoing work needed in the compiler to make SE-0025 work
> fully. Certainly, hundreds of hours would not be required to roll back
> corelibs-foundation alone. The exact effort required is knowable, too, as
> one can fork and migrate all uses of private to fileprivate right now and
> see how long it takes.
>

Update: with the caveat that corelibs-foundation tests are incomplete, it
took me about 15 mins to migrate all uses of private to fileprivate. The
tricky thing is that one has to do case-sensitive find-and-replace, and to
replace all instances of "filefileprivate" in a second round. It does not
appear that corelibs-foundation actually uses new `private` in a way that
migrating to `fileprivate` results in invalid redeclarations anywhere.


On Fri, Mar 24, 2017 at 22:38 Drew Crawford via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>>
>> On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@gbis.com) wrote:
>>
>> This is exactly the problem. Both for access controls and dispatch.
>>
>>
>> How would you respond to clattner's position piece
>> 
>>  on
>> this?  He disputes this point directly:
>>
>> Swift is another case of a hybrid model: its semantics provide
>> predictability between obviously static (structs, enums, and global funcs)
>> and obviously dynamic (classes, protocols, and closures) constructs.  A
>> focus of Swift (like Java and Javascript) is to provide an apparently
>> simple programming model.  However, Swift also intentionally "cheats" in
>> its global design by mixing in a few tricks to make the dynamic parts of
>> the language optimizable by a static compiler in many common cases...
>>
>> The upshot of this is that Swift isn’t squarely in either of the static
>> or dynamic camps: it aims to provide a very predictable performance model
>> (someone writing a bootloader or firmware can stick to using Swift structs
>> and have a simple guarantee of no dynamic overhead or runtime dependence)
>> while also providing an expressive and clean high level programming model -
>> simplifying learning and the common case where programmers don’t care to
>> count cycles.
>>
>> Is it?  Can you point to an instance where a member of the core team said
>> they are aiming for “plenty of overlap”?
>>
>> See above
>>
>> Honestly, most of your examples could just be split into multiple files.
>>
>> Specific arguments were advanced in those examples that they cannot.  Can
>> you refute them?
>>
>> You are conflating effort by the swift design and implementation
>> community with your personal effort around migration.
>>
>> No, I am referencing a Swift@IBM developer who reported that
>>
>> the open-source version of Foundation still has a long way to go to get
>> the level of quality of the existing Objective-C frameworks, and we already
>> have enough work to do without having to go make a bunch of arbitrary
>> changes and risk a bunch of regressions because someone doesn't like a
>> keyword... Accepting this proposal would waste hundreds of person-hours of
>> work...
>>
>> ___
>> 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] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 10:28:43 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

I'm not sure where you're reading that Chris thinks the current design reaches 
the stated aims to his satisfaction.
I'm pretty sure it's a fair assumption that when he introduces the 
static/dynamic system to illustrate the design goals of Swift, he means those 
goals can be seen in that feature to some significant extent.

"We intentionally want Swift to have a common 'center of gravity' and be an 
'opinionated' language, rather than fall to the 'design by committee' approach 
that leads to a watered-down design."  This is diametrically opposite to 
"shipping a full toolbox with plenty of overlap."
Chris has elaborated on this elsewhere:

Another thing to keep in mind is that Swift is opinionated, I guess is the way 
to say it. It really does encourage you to do the right thing where it can. For 
example, if you use var for everything, the Swift compiler [1:21:30] will say, 
hey, you marked this as a var but it could be a let, and let me fix it for you. 
That's just its subtle way of encouraging you to use immutable values, which is 
a very small thing, but it's just pushing you in the way that it thinks leads 
to a better code. Immutability for a local variable doesn't matter that much 
except that it communicates something more to the person who has to read and 
maintain your code.

I think that Swift really does [1:22:00] encourage you down the right lines in 
some ways. But on the other hand, in other places where you're saying, "Should 
something be a class or a struct?”, the trade-offs are more nuanced and it's a 
harder thing, and the Swift compiler can't just know what problem it is that 
you want to solve, so it can't help you with that.

`let` and `var` are "redundant" in the same way as private/fileprivate; one can 
effectively replace the other.  Far from advocating we should eliminate the 
redundant keyword, he argues the compiler should encourage it, because "Swift 
is an opinionated language" and an argument to the principle of least power.  
The analogous idea would be if the compiler offered a fixit to change 
"fileprivate" to "private" where legal.  Actually, that would be an interesting 
proposal, especially since some believe private/fileprivate is hard to learn.

But "Swift is an opinionated language" is not a battlecry for eliminating 
"redundant" keywords, it is an exhortation to use them correctly.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 10:57 PM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 24, 2017, at 8:38 PM, Drew Crawford 
> wrote:
>
> On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@gbis.com) wrote:
>
> This is exactly the problem. Both for access controls and dispatch.
>
>
> How would you respond to clattner's position piece
> 
>  on
> this?  He disputes this point directly:
>
>
> Swift is another case of a hybrid model: its semantics provide
> predictability between obviously static (structs, enums, and global funcs)
> and obviously dynamic (classes, protocols, and closures) constructs.  A
> focus of Swift (like Java and Javascript) is to provide an apparently
> simple programming model.  However, Swift also intentionally "cheats" in
> its global design by mixing in a few tricks to make the dynamic parts of
> the language optimizable by a static compiler in many common cases...
> The upshot of this is that Swift isn’t squarely in either of the static or
> dynamic camps: it aims to provide a very predictable performance model
> (someone writing a bootloader or firmware can stick to using Swift structs
> and have a simple guarantee of no dynamic overhead or runtime dependence)
> while also providing an expressive and clean high level programming model -
> simplifying learning and the common case where programmers don’t care to
> count cycles.
>
>
> I agree with him.  I think you must be missing my point.
>
> Is it?  Can you point to an instance where a member of the core team said
> they are aiming for “plenty of overlap”?
>
> See above
>
> I don’t see where you are reading this from what he said.
>

In fact, I read Chris's position piece as pretty clearly rejecting the
"plenty of overlap" claim. An overlap would involve two or more things that
have at least partly redundant function. Chris talks of a hybrid model:
i.e., one thing, not two or more, melded from disparate parts in such a way
that there is no overlap. His whole text is justifying the particular
hybrid chosen. Offering both static and dynamic as two separate models is
out of the question; the debate at hand is not _whether_ there should be
one or two models in Swift, but _how_ two are to be combined into one.


> Honestly, most of your examples could just be split into multiple files.
>
> Specific arguments were advanced in those examples that they cannot.  Can
> you refute them?
>
> Honestly those felt like ill-advised hacks to me (especially shadowing in
> the same file).  As Xiaodi suggested earlier, you could use a linter if you
> really wanted to enforce them.  I personally use an underscore before
> variables I don’t want to expose outside the type.
>
> I would be interested to know about other use-cases you have, because it
> may be possible to design for them in a way which does not require scoped
> private.
>
>
> You are conflating effort by the swift design and implementation community
> with your personal effort around migration.
>
> No, I am referencing a Swift@IBM developer who reported that
>
> the open-source version of Foundation still has a long way to go to get
> the level of quality of the existing Objective-C frameworks, and we already
> have enough work to do without having to go make a bunch of arbitrary
> changes and risk a bunch of regressions because someone doesn't like a
> keyword... Accepting this proposal would waste hundreds of person-hours of
> work…
>
> Yes you are.  You can make a separate argument that migration will be an
> issue. (and if you recall my own vote was to wait on the implementation and
> make all of the changes at once in Swift 5).
>
> I am asking about the time of the Swift team and surrounding
> design/implementation community.  Do you honestly think that supporting
> both scope and file-based access control is important enough that we should
> spend the time/effort to fix the current issues in another way that allows
> both?
>
> Thanks,
> Jon
>
>
>
>
>
>
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

> On Mar 24, 2017, at 8:38 PM, Drew Crawford  wrote:
> On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@gbis.com 
> ) wrote:
> 
>> This is exactly the problem. Both for access controls and dispatch.
> 
> How would you respond to clattner's position piece 
> 
>  on this?  He disputes this point directly:
> 
>> Swift is another case of a hybrid model: its semantics provide 
>> predictability between obviously static (structs, enums, and global funcs) 
>> and obviously dynamic (classes, protocols, and closures) constructs.  A 
>> focus of Swift (like Java and Javascript) is to provide an apparently simple 
>> programming model.  However, Swift also intentionally "cheats" in its global 
>> design by mixing in a few tricks to make the dynamic parts of the language 
>> optimizable by a static compiler in many common cases...
>> The upshot of this is that Swift isn’t squarely in either of the static or 
>> dynamic camps: it aims to provide a very predictable performance model 
>> (someone writing a bootloader or firmware can stick to using Swift structs 
>> and have a simple guarantee of no dynamic overhead or runtime dependence) 
>> while also providing an expressive and clean high level programming model - 
>> simplifying learning and the common case where programmers don’t care to 
>> count cycles.

I agree with him.  I think you must be missing my point.

>> Is it?  Can you point to an instance where a member of the core team said 
>> they are aiming for “plenty of overlap”?
>> 
> See above
> 
I don’t see where you are reading this from what he said.


>> Honestly, most of your examples could just be split into multiple files.
> 
> Specific arguments were advanced in those examples that they cannot.  Can you 
> refute them?
> 
Honestly those felt like ill-advised hacks to me (especially shadowing in the 
same file).  As Xiaodi suggested earlier, you could use a linter if you really 
wanted to enforce them.  I personally use an underscore before variables I 
don’t want to expose outside the type.

I would be interested to know about other use-cases you have, because it may be 
possible to design for them in a way which does not require scoped private.


>> You are conflating effort by the swift design and implementation community 
>> with your personal effort around migration.
> 
> No, I am referencing a Swift@IBM developer who reported that 
> 
>> the open-source version of Foundation still has a long way to go to get the 
>> level of quality of the existing Objective-C frameworks, and we already have 
>> enough work to do without having to go make a bunch of arbitrary changes and 
>> risk a bunch of regressions because someone doesn't like a keyword... 
>> Accepting this proposal would waste hundreds of person-hours of work…
Yes you are.  You can make a separate argument that migration will be an issue. 
(and if you recall my own vote was to wait on the implementation and make all 
of the changes at once in Swift 5).

I am asking about the time of the Swift team and surrounding 
design/implementation community.  Do you honestly think that supporting both 
scope and file-based access control is important enough that we should spend 
the time/effort to fix the current issues in another way that allows both?

Thanks,
Jon





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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

As Chris has said in the past, the core team is willing to endure a
substantial amount of implementation pain to present a superior experience
for the end user. In any case, I expect that the work needed to roll back
SE-0025 in the core libraries will likely be comparable if not less than
the remaining ongoing work needed in the compiler to make SE-0025 work
fully. Certainly, hundreds of hours would not be required to roll back
corelibs-foundation alone. The exact effort required is knowable, too, as
one can fork and migrate all uses of private to fileprivate right now and
see how long it takes.
On Fri, Mar 24, 2017 at 22:38 Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>
> On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@gbis.com) wrote:
>
> This is exactly the problem. Both for access controls and dispatch.
>
>
> How would you respond to clattner's position piece
> 
>  on
> this?  He disputes this point directly:
>
> Swift is another case of a hybrid model: its semantics provide
> predictability between obviously static (structs, enums, and global funcs)
> and obviously dynamic (classes, protocols, and closures) constructs.  A
> focus of Swift (like Java and Javascript) is to provide an apparently
> simple programming model.  However, Swift also intentionally "cheats" in
> its global design by mixing in a few tricks to make the dynamic parts of
> the language optimizable by a static compiler in many common cases...
>
> The upshot of this is that Swift isn’t squarely in either of the static or
> dynamic camps: it aims to provide a very predictable performance model
> (someone writing a bootloader or firmware can stick to using Swift structs
> and have a simple guarantee of no dynamic overhead or runtime dependence)
> while also providing an expressive and clean high level programming model -
> simplifying learning and the common case where programmers don’t care to
> count cycles.
>
> Is it?  Can you point to an instance where a member of the core team said
> they are aiming for “plenty of overlap”?
>
> See above
>
> Honestly, most of your examples could just be split into multiple files.
>
> Specific arguments were advanced in those examples that they cannot.  Can
> you refute them?
>
> You are conflating effort by the swift design and implementation community
> with your personal effort around migration.
>
> No, I am referencing a Swift@IBM developer who reported that
>
> the open-source version of Foundation still has a long way to go to get
> the level of quality of the existing Objective-C frameworks, and we already
> have enough work to do without having to go make a bunch of arbitrary
> changes and risk a bunch of regressions because someone doesn't like a
> keyword... Accepting this proposal would waste hundreds of person-hours of
> work...
>
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@gbis.com) wrote:

This is exactly the problem. Both for access controls and dispatch.


How would you respond to clattner's position piece on this?  He disputes this 
point directly:

Swift is another case of a hybrid model: its semantics provide predictability 
between obviously static (structs, enums, and global funcs) and obviously 
dynamic (classes, protocols, and closures) constructs.  A focus of Swift (like 
Java and Javascript) is to provide an apparently simple programming model.  
However, Swift also intentionally "cheats" in its global design by mixing in a 
few tricks to make the dynamic parts of the language optimizable by a static 
compiler in many common cases...
The upshot of this is that Swift isn’t squarely in either of the static or 
dynamic camps: it aims to provide a very predictable performance model (someone 
writing a bootloader or firmware can stick to using Swift structs and have a 
simple guarantee of no dynamic overhead or runtime dependence) while also 
providing an expressive and clean high level programming model - simplifying 
learning and the common case where programmers don’t care to count cycles.
Is it?  Can you point to an instance where a member of the core team said they 
are aiming for “plenty of overlap”?

See above

Honestly, most of your examples could just be split into multiple files.
Specific arguments were advanced in those examples that they cannot.  Can you 
refute them?

You are conflating effort by the swift design and implementation community with 
your personal effort around migration.
No, I am referencing a Swift@IBM developer who reported that 

the open-source version of Foundation still has a long way to go to get the 
level of quality of the existing Objective-C frameworks, and we already have 
enough work to do without having to go make a bunch of arbitrary changes and 
risk a bunch of regressions because someone doesn't like a keyword... Accepting 
this proposal would waste hundreds of person-hours of work...
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

Chris's actual quote was:

"We intentionally want Swift to have a common 'center of gravity' and be an
'opinionated' language, rather than fall to the 'design by committee'
approach that leads to a watered-down design."

This is diametrically opposite to "shipping a full toolbox with plenty of
overlap."


On Fri, Mar 24, 2017 at 22:21 Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 24, 2017, at 6:45 PM, Drew Crawford 
> wrote:
>
> On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jh...@gbis.com) wrote:
>
> It isn’t the fact that there are multiple models, but they way those
> models interact with each other in the brain.  You can actually have lots
> of different models without causing confusion, as long as the models fit
> well together.  It also isn’t the number of access levels that is a
> problem.  For example, you can have a ton of shirt sizes (XS, S, M, L, XL,
> XXL, 3XL) and it doesn’t cause more confusion as you add more sizes because
> they don’t conflict with one another.
>
> A big part of the issue with our current access scheme is how similar the
> concepts are without being the same.  That is then made worse by the fact
> that they have been given similar names.
>
> It is unclear what distinction you intend to draw here.  For example,
> value types and reference types are similar without being the same.  The
> names of both concepts also contain the substring "type".  So the
> difference you draw between that situation and the private/fileprivate
> situation is not immediately clear.
>
> The distinction between value and reference types is one of the most
> confusing aspects of learning to program. We are helped a bit by the fact
> that we use the concrete Class, Struct, and Enum.  Many programmers just
> think of Classes as behaving differently than Structs/Enums and don’t
> really think about it as value vs reference.  We never write valueType or
> referenceType in swift (only when having abstract discussions here on
> Evolution).  Notice also that swift doesn’t use the term
> “pass-by-reference”.  It has explicitly avoided using those terms in actual
> swift code.
>
> I agree with you about statically vs dynamically dispatched being an
> issue.  For the most part, Swift tries to make it so we don’t ever have to
> think about it, but when the distinction does poke through, it can be
> confusing.  I think we will need to do some redesign work here when more
> dynamic features are added.  I had a proposal a while back to allow power
> users to force static dispatch by disambiguating the implementation which
> gets used. I will probably re-propose that when it seems in scope.
>
> It may help if I clarify that a mental model is not how something actually
> works, but rather our model of how we *think* it works.  Mental models are
> almost always incorrect, but they are good enough to get by... for the most
> part. (https://www.nngroup.com/articles/mental-models/)
>
> In your examples above, Swift is projecting a system image which is much
> simpler than the underlying concepts (e.g. your statement about static vs
> dynamic typing that: "I would guess the vast majority of Swift developers
> are not aware there's a difference at all”).  This helps to avoid confusion
> (except where rough spots poke through the facade).
>
> For access controls, the user is being presented with the full complexity
> of that choice directly.
>
> Here we have two superficially similar tools with slightly different
> features and performance characteristics, and for most problems it does not
> even matter which one you choose.
>
> This is exactly the problem. Both for access controls and dispatch.
>
> IMO shipping a full toolbox with plenty of overlap is one of the core
> values of Swift.
>
> Is it?  Can you point to an instance where a member of the core team said
> they are aiming for “plenty of overlap”?
>
>
> Do you feel that allowing both scoped private & file-based private is
> actually important enough to warrant the significant design work it would
> take to bring it up to par with these other features?
>
> It is not clear to me what design work is actually outstanding.  I would
> love to see submodules, but that seems only indirectly related to
> visibility keywords, and I'm not aware of what you seem to believe we need.
>
> I do use scoped access extensively, and I've left some examples of that
> upthread.
>
> Honestly, most of your examples could just be split into multiple files.
> They might also benefit from submodules.
>
>
> It is not impossible, but it really doesn’t feel worth the effort to me
> (say compared to using that time/energy/thought to check off features from
> the generics manifesto).
>
> Rather, as Carl Brown argued, it would take a lot of time/energy to
> migrate even the official projects off of private/fileprivate.  Keeping
> what we have is free, change is what is expensive, and this proposal is
> change.
>
> You are conflating 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

I'm not sure where you're reading that Chris thinks the current design
reaches the stated aims to his satisfaction.

Again, I agree with the stated design goals for static/dynamic dispatch,
but I don't think they've been met.
On Fri, Mar 24, 2017 at 22:23 Drew Crawford  wrote:

>
>
>
> On March 24, 2017 at 10:11:07 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> I agree absolutely with those aims: very predictable performance,
> expressive and clean model, simplified learning and common cases. I'm
> arguing that the giant table of dispatch rules (see:
> http://raizlabscom-wpengine.netdna-ssl.com/dev/wp-content/uploads/sites/10/2016/12/Summary-3.png)
>  does
> not reach that goal.
>
> But clattner believes it does.  This is clearer in his original, which is
> why I quoted it:
>
> predictable performance model (someone writing a bootloader or firmware
> can stick to using Swift structs and have a simple guarantee of no dynamic
> overhead or runtime dependence)
>
> ("predictable performance" to clattner means "value types are direct")
>
> while also providing an expressive and clean high level programming model
> - simplifying learning and the common case where programmers don’t care to
> count cycles.
>
> ("simplifying the learning" to clattner means that the programming model
> appears dynamic and the real performance characteristic is hidden.)
>
> We know (because clattner told us here) what the design goal of Swift is
> with respect to static/dynamic dispatch.  You may not agree with it, but
> that is another issue.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 10:11:07 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

I agree absolutely with those aims: very predictable performance, expressive 
and clean model, simplified learning and common cases. I'm arguing that the 
giant table of dispatch rules (see: 
http://raizlabscom-wpengine.netdna-ssl.com/dev/wp-content/uploads/sites/10/2016/12/Summary-3.png)
 does not reach that goal.
But clattner believes it does.  This is clearer in his original, which is why I 
quoted it:

predictable performance model (someone writing a bootloader or firmware can 
stick to using Swift structs and have a simple guarantee of no dynamic overhead 
or runtime dependence)
("predictable performance" to clattner means "value types are direct")

while also providing an expressive and clean high level programming model - 
simplifying learning and the common case where programmers don’t care to count 
cycles.
("simplifying the learning" to clattner means that the programming model 
appears dynamic and the real performance characteristic is hidden.)

We know (because clattner told us here) what the design goal of Swift is with 
respect to static/dynamic dispatch.  You may not agree with it, but that is 
another issue.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

> On Mar 24, 2017, at 8:10 PM, Xiaodi Wu  wrote:
> 
> On Fri, Mar 24, 2017 at 9:55 PM, Drew Crawford  > wrote:
> On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (xiaodi...@gmail.com 
> ) wrote:
> 
>> Figuring out what's statically vs. dynamically dispatched can be very 
>> difficult with Swift. Although each rule is defensible when dissected 
>> individually, the overall scheme once `final`, `dynamic`, `@objc`, etc. are 
>> included is supremely inelegant. Far from being an example of a core value, 
>> I would say it's an example of a major weakness. I see one of the key goals 
>> of the Swift evolution process as reducing and, where possible, eliminating 
>> such designs from the language.
> 
> How would you respond to clattner's position piece 
> 
>  on this?  It seems to contradict you on exactly this point, e.g.
> 
>> Swift is another case of a hybrid model: its semantics provide 
>> predictability between obviously static (structs, enums, and global funcs) 
>> and obviously dynamic (classes, protocols, and closures) constructs.  A 
>> focus of Swift (like Java and Javascript) is to provide an apparently simple 
>> programming model.  However, Swift also intentionally "cheats" in its global 
>> design by mixing in a few tricks to make the dynamic parts of the language 
>> optimizable by a static compiler in many common cases...
>> The upshot of this is that Swift isn’t squarely in either of the static or 
>> dynamic camps: it aims to provide a very predictable performance model 
>> (someone writing a bootloader or firmware can stick to using Swift structs 
>> and have a simple guarantee of no dynamic overhead or runtime dependence) 
>> while also providing an expressive and clean high level programming model - 
>> simplifying learning and the common case where programmers don’t care to 
>> count cycles.
> 
> 
> I agree absolutely with those aims: very predictable performance, expressive 
> and clean model, simplified learning and common cases. I'm arguing that the 
> giant table of dispatch rules (see: 
> http://raizlabscom-wpengine.netdna-ssl.com/dev/wp-content/uploads/sites/10/2016/12/Summary-3.png
>  
> )
>  does not reach that goal. At least half a dozen independent threads have 
> been started on this list alone about why methods in protocol extensions can 
> only be shadowed but not overridden. The goal of evolution, IMO, is precisely 
> to refine the "apparent model" as much as possible, eliminating as many of 
> these exposed jagged edges wherever it is reasonable to have the compiler 
> make it "just work."
> 
> The same argument goes here for `fileprivate` and new `private`. I don't see 
> anyone who thinks that the current set of access modifiers is "clean"; and no 
> one has argued that the expanded set of access modifiers "simplified learning 
> and common cases." Moreover, it enables no performance wins. In fact, it does 
> the *opposite* of what Chris is praising in his email. There, he says that 
> Swift "provide[s] an apparently simple programming model" for dispatch but 
> "cheats" under the covers to recover additional performance wins; here, 
> access modifiers in Swift 3 deliberately expose a more complex model than 
> before, but does not gain for the compiler any additional optimization 
> opportunities from doing so.

I just wrote up a long response to Drew’s earlier email, but you said it much 
more elegantly here :-)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

> On Mar 24, 2017, at 6:45 PM, Drew Crawford  wrote:
> On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jh...@gbis.com 
> ) wrote:
> 
>> It isn’t the fact that there are multiple models, but they way those models 
>> interact with each other in the brain.  You can actually have lots of 
>> different models without causing confusion, as long as the models fit well 
>> together.  It also isn’t the number of access levels that is a problem.  For 
>> example, you can have a ton of shirt sizes (XS, S, M, L, XL, XXL, 3XL) and 
>> it doesn’t cause more confusion as you add more sizes because they don’t 
>> conflict with one another.
>> 
>> A big part of the issue with our current access scheme is how similar the 
>> concepts are without being the same.  That is then made worse by the fact 
>> that they have been given similar names.
> 
> It is unclear what distinction you intend to draw here.  For example, value 
> types and reference types are similar without being the same.  The names of 
> both concepts also contain the substring "type".  So the difference you draw 
> between that situation and the private/fileprivate situation is not 
> immediately clear.
> 
The distinction between value and reference types is one of the most confusing 
aspects of learning to program. We are helped a bit by the fact that we use the 
concrete Class, Struct, and Enum.  Many programmers just think of Classes as 
behaving differently than Structs/Enums and don’t really think about it as 
value vs reference.  We never write valueType or referenceType in swift (only 
when having abstract discussions here on Evolution).  Notice also that swift 
doesn’t use the term “pass-by-reference”.  It has explicitly avoided using 
those terms in actual swift code.

I agree with you about statically vs dynamically dispatched being an issue.  
For the most part, Swift tries to make it so we don’t ever have to think about 
it, but when the distinction does poke through, it can be confusing.  I think 
we will need to do some redesign work here when more dynamic features are 
added.  I had a proposal a while back to allow power users to force static 
dispatch by disambiguating the implementation which gets used. I will probably 
re-propose that when it seems in scope.

It may help if I clarify that a mental model is not how something actually 
works, but rather our model of how we *think* it works.  Mental models are 
almost always incorrect, but they are good enough to get by... for the most 
part. (https://www.nngroup.com/articles/mental-models/ 
)

In your examples above, Swift is projecting a system image which is much 
simpler than the underlying concepts (e.g. your statement about static vs 
dynamic typing that: "I would guess the vast majority of Swift developers are 
not aware there's a difference at all”).  This helps to avoid confusion (except 
where rough spots poke through the facade).

For access controls, the user is being presented with the full complexity of 
that choice directly.
> Here we have two superficially similar tools with slightly different features 
> and performance characteristics, and for most problems it does not even 
> matter which one you choose.  
> 
This is exactly the problem. Both for access controls and dispatch.

> IMO shipping a full toolbox with plenty of overlap is one of the core values 
> of Swift.
> 
Is it?  Can you point to an instance where a member of the core team said they 
are aiming for “plenty of overlap”?


>> Do you feel that allowing both scoped private & file-based private is 
>> actually important enough to warrant the significant design work it would 
>> take to bring it up to par with these other features? 
> 
> It is not clear to me what design work is actually outstanding.  I would love 
> to see submodules, but that seems only indirectly related to visibility 
> keywords, and I'm not aware of what you seem to believe we need.
> 
> I do use scoped access extensively, and I've left some examples of that 
> upthread.
> 
Honestly, most of your examples could just be split into multiple files. They 
might also benefit from submodules.


>> It is not impossible, but it really doesn’t feel worth the effort to me (say 
>> compared to using that time/energy/thought to check off features from the 
>> generics manifesto).
> 
> Rather, as Carl Brown argued, it would take a lot of time/energy to migrate 
> even the official projects off of private/fileprivate.  Keeping what we have 
> is free, change is what is expensive, and this proposal is change.
> 
You are conflating effort by the swift design and implementation community with 
your personal effort around migration.
 

>>  In general, Swift is an opinionated language
> 
> Not clear what you mean here either.  Swift is clearly less opinionated than 
> ObjC for example.  I am having trouble connecting this claim to a practical 
> application.
> 
Oh, 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 9:55 PM, Drew Crawford 
wrote:

>
>
>
> On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> Figuring out what's statically vs. dynamically dispatched can be very
> difficult with Swift. Although each rule is defensible when dissected
> individually, the overall scheme once `final`, `dynamic`, `@objc`, etc. are
> included is supremely inelegant. Far from being an example of a core value,
> I would say it's an example of a major weakness. I see one of the key goals
> of the Swift evolution process as reducing and, where possible, eliminating
> such designs from the language.
>
> How would you respond to clattner's position piece
> 
>  on
> this?  It seems to contradict you on exactly this point, e.g.
>
> Swift is another case of a hybrid model: its semantics provide
> predictability between obviously static (structs, enums, and global funcs)
> and obviously dynamic (classes, protocols, and closures) constructs.  A
> focus of Swift (like Java and Javascript) is to provide an apparently
> simple programming model.  However, Swift also intentionally "cheats" in
> its global design by mixing in a few tricks to make the dynamic parts of
> the language optimizable by a static compiler in many common cases...
>
> The upshot of this is that Swift isn’t squarely in either of the static or
> dynamic camps: it aims to provide a very predictable performance model
> (someone writing a bootloader or firmware can stick to using Swift structs
> and have a simple guarantee of no dynamic overhead or runtime dependence)
> while also providing an expressive and clean high level programming model -
> simplifying learning and the common case where programmers don’t care to
> count cycles.
>
>
I agree absolutely with those aims: very predictable performance,
expressive and clean model, simplified learning and common cases. I'm
arguing that the giant table of dispatch rules (see:
http://raizlabscom-wpengine.netdna-ssl.com/dev/wp-content/uploads/sites/10/2016/12/Summary-3.png)
does
not reach that goal. At least half a dozen independent threads have been
started on this list alone about why methods in protocol extensions can
only be shadowed but not overridden. The goal of evolution, IMO, is
precisely to refine the "apparent model" as much as possible, eliminating
as many of these exposed jagged edges wherever it is reasonable to have the
compiler make it "just work."

The same argument goes here for `fileprivate` and new `private`. I don't
see anyone who thinks that the current set of access modifiers is "clean";
and no one has argued that the expanded set of access modifiers "simplified
learning and common cases." Moreover, it enables no performance wins. In
fact, it does the *opposite* of what Chris is praising in his email. There,
he says that Swift "provide[s] an apparently simple programming model" for
dispatch but "cheats" under the covers to recover additional performance
wins; here, access modifiers in Swift 3 deliberately expose a more complex
model than before, but does not gain for the compiler any additional
optimization opportunities from doing so.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

Figuring out what's statically vs. dynamically dispatched can be very difficult 
with Swift. Although each rule is defensible when dissected individually, the 
overall scheme once `final`, `dynamic`, `@objc`, etc. are included is supremely 
inelegant. Far from being an example of a core value, I would say it's an 
example of a major weakness. I see one of the key goals of the Swift evolution 
process as reducing and, where possible, eliminating such designs from the 
language.
How would you respond to clattner's position piece on this?  It seems to 
contradict you on exactly this point, e.g.

Swift is another case of a hybrid model: its semantics provide predictability 
between obviously static (structs, enums, and global funcs) and obviously 
dynamic (classes, protocols, and closures) constructs.  A focus of Swift (like 
Java and Javascript) is to provide an apparently simple programming model.  
However, Swift also intentionally "cheats" in its global design by mixing in a 
few tricks to make the dynamic parts of the language optimizable by a static 
compiler in many common cases...
The upshot of this is that Swift isn’t squarely in either of the static or 
dynamic camps: it aims to provide a very predictable performance model (someone 
writing a bootloader or firmware can stick to using Swift structs and have a 
simple guarantee of no dynamic overhead or runtime dependence) while also 
providing an expressive and clean high level programming model - simplifying 
learning and the common case where programmers don’t care to count cycles.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Fri, Mar 24, 2017 at 8:45 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>
> On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jh...@gbis.com) wrote:
>
> It isn’t the fact that there are multiple models, but they way those
> models interact with each other in the brain.  You can actually have lots
> of different models without causing confusion, as long as the models fit
> well together.  It also isn’t the number of access levels that is a
> problem.  For example, you can have a ton of shirt sizes (XS, S, M, L, XL,
> XXL, 3XL) and it doesn’t cause more confusion as you add more sizes because
> they don’t conflict with one another.
>
> A big part of the issue with our current access scheme is how similar the
> concepts are without being the same.  That is then made worse by the fact
> that they have been given similar names.
>
> It is unclear what distinction you intend to draw here.  For example,
> value types and reference types are similar without being the same.  The
> names of both concepts also contain the substring "type".  So the
> difference you draw between that situation and the private/fileprivate
> situation is not immediately clear.
>
> Note also that your list above is a list of typical stumbling blocks for
> new programmers in most languages. Swift has actually done a remarkable job
> with most of these through careful design of the way that they are framed /
> exposed to the programmer.  In general, these things are well separated
> from each other.
>
> I do not think Swift has done even a *good* job framing these concepts.
> For example
>
> protocol Foo {
>
> func foo() { }
>
> }
>
> extension Foo {
>
> func bar() {}
>
> }
>
> One of these is statically dispatched and the other one is dynamically
> dispatched.  I would guess the vast majority of Swift developers are not
> aware there's a difference at all, let alone can explain why one is slower
> in a benchmark.
>
> Swift is good at giving programmers flexibility in their tools.  Here we
> have two superficially similar tools with slightly different features and
> performance characteristics, and for most problems it does not even matter
> which one you choose.  IMO shipping a full toolbox with plenty of overlap
> is one of the core values of Swift.
>

I could hardly disagree more with this opinion. Figuring out what's
statically vs. dynamically dispatched can be very difficult with Swift.
Although each rule is defensible when dissected individually, the overall
scheme once `final`, `dynamic`, `@objc`, etc. are included is supremely
inelegant. Far from being an example of a core value, I would say it's an
example of a major weakness. I see one of the key goals of the Swift
evolution process as reducing and, where possible, eliminating such designs
from the language.

I would suggest that the practicable reason we are talking about removing
> private/fileprivate instead of protocol/extension or reference/value is
> that while `extension` etc. makes your code more powerful, `private` makes
> it less powerful.  It is not obvious to everyone why less power is
> desirable and so here we are.
>
> Do you feel that allowing both scoped private & file-based private is
> actually important enough to warrant the significant design work it would
> take to bring it up to par with these other features?
>
> It is not clear to me what design work is actually outstanding.  I would
> love to see submodules, but that seems only indirectly related to
> visibility keywords, and I'm not aware of what you seem to believe we need.
>
> I do use scoped access extensively, and I've left some examples of that
> upthread.
>
> It is not impossible, but it really doesn’t feel worth the effort to me
> (say compared to using that time/energy/thought to check off features from
> the generics manifesto).
>
> Rather, as Carl Brown argued, it would take a lot of time/energy to
> migrate even the official projects off of private/fileprivate.  Keeping
> what we have is free, change is what is expensive, and this proposal is
> change.
>
>  In general, Swift is an opinionated language
>
> Not clear what you mean here either.  Swift is clearly less opinionated
> than ObjC for example.  I am having trouble connecting this claim to a
> practical application.
>
> ___
> 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] [Review] SE-0159: Fix Private Access Levels (undermining my own case)

[Matt Gallagher via swift-evolution]

Without retracting any of the statements I made in my previous message:


https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034336.html
 


I'd like to point out that on a 1 to 10 scale of Swift past and potential 
changes that I'm passionate about – with a perfect 10 reserved for the Swift 
Ownership Manifesto and a 1 being something trivial like SE-0106 (Add a macOS 
Alias for the OSX Platform) – this issue rates around a 3 for me. I care but 
not a lot.

I'm mentioning this because a number of people on Twitter are commenting that 
discussion on this issue has gotten a little quarrelsome and I'm sorry if I've 
had a part in that. I only weighed-in to state that I have an opinion, not to 
draw a line in the sand and dig a bunker.

I'm fully aware that scoped access modifiers are basically an issue of 
aesthetics; allowing you to keep two entities that need interface-hiding in the 
same file, rather than in separate files. On that point, the whole issue could 
be seen as bike-shedding.

Further, even for my own "primary use case" that I personally gave here:

https://gist.github.com/mattgallagher/b93c6e587488d60a68e4cc0318a7c356 


I can think of additional abstractions that would make the `private` members 
inaccessible while still keeping both View-Model and View-Binding in the same 
file e.g.

a) Wrapping the `input` and `output` members in a generic wrapper that 
lives in another file (and so can take advantage of interface-hiding between 
files) and handles the required input-hidden/managed, output-exposed pattern

b) Building a series of libdispatch/reactive/whatever closures up in 
the `init` method that contain and self-manage the internallyMaintainedState – 
so it doesn't need to reside the View-Model at all – and merely store an opaque 
KeepAlive instance in the View-Model to anchor the lifetime

Involving more abstractions like this or setting up an opaque, self-managing 
entities does mean more work – both implementation time and conceptual 
gymnastics – but these approaches could deliver similar aesthetics without 
needing scoped access modifiers. There are potential performance implications 
involved in adding abstractions and closures but these can be handled as they 
arise.

Regards,
Matt Gallagher.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

Sorry, listing should read

protocol Foo {

    func foo()

}

extension Foo {

    func foo() {}

    func bar() {}

}



On March 24, 2017 at 8:46:02 PM, Drew Crawford (d...@sealedabstract.com) wrote:

protocol Foo {

    func foo() { }

}

extension Foo {

    func bar() {}

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 7:53:09 PM, Jonathan Hull (jh...@gbis.com) wrote:

It isn’t the fact that there are multiple models, but they way those models 
interact with each other in the brain.  You can actually have lots of different 
models without causing confusion, as long as the models fit well together.  It 
also isn’t the number of access levels that is a problem.  For example, you can 
have a ton of shirt sizes (XS, S, M, L, XL, XXL, 3XL) and it doesn’t cause more 
confusion as you add more sizes because they don’t conflict with one another.

A big part of the issue with our current access scheme is how similar the 
concepts are without being the same.  That is then made worse by the fact that 
they have been given similar names.
It is unclear what distinction you intend to draw here.  For example, value 
types and reference types are similar without being the same.  The names of 
both concepts also contain the substring "type".  So the difference you draw 
between that situation and the private/fileprivate situation is not immediately 
clear.

Note also that your list above is a list of typical stumbling blocks for new 
programmers in most languages. Swift has actually done a remarkable job with 
most of these through careful design of the way that they are framed / exposed 
to the programmer.  In general, these things are well separated from each 
other. 
I do not think Swift has done even a *good* job framing these concepts.  For 
example

protocol Foo {

    func foo() { }

}

extension Foo {

    func bar() {}

}

One of these is statically dispatched and the other one is dynamically 
dispatched.  I would guess the vast majority of Swift developers are not aware 
there's a difference at all, let alone can explain why one is slower in a 
benchmark.

Swift is good at giving programmers flexibility in their tools.  Here we have 
two superficially similar tools with slightly different features and 
performance characteristics, and for most problems it does not even matter 
which one you choose.  IMO shipping a full toolbox with plenty of overlap is 
one of the core values of Swift.

I would suggest that the practicable reason we are talking about removing 
private/fileprivate instead of protocol/extension or reference/value is that 
while `extension` etc. makes your code more powerful, `private` makes it less 
powerful.  It is not obvious to everyone why less power is desirable and so 
here we are.

Do you feel that allowing both scoped private & file-based private is actually 
important enough to warrant the significant design work it would take to bring 
it up to par with these other features? 
It is not clear to me what design work is actually outstanding.  I would love 
to see submodules, but that seems only indirectly related to visibility 
keywords, and I'm not aware of what you seem to believe we need.

I do use scoped access extensively, and I've left some examples of that 
upthread.

It is not impossible, but it really doesn’t feel worth the effort to me (say 
compared to using that time/energy/thought to check off features from the 
generics manifesto).
Rather, as Carl Brown argued, it would take a lot of time/energy to migrate 
even the official projects off of private/fileprivate.  Keeping what we have is 
free, change is what is expensive, and this proposal is change.

 In general, Swift is an opinionated language
Not clear what you mean here either.  Swift is clearly less opinionated than 
ObjC for example.  I am having trouble connecting this claim to a practical 
application.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

> On Mar 24, 2017, at 9:41 AM, Drew Crawford  wrote:
> 
>> There are a couple of problems with the design which are causing Cognitive 
>> Dissonance:
>> 
>> 1) Private & fileprivate require very different mental models to operate them
>> 2) They are named very similarly to each other
>> 3) There is a third concept of “private to the type” which requires a third 
>> mental model, but is spelled the same way in other languages 
> 
> 
> How would you respond to the allegation that supporting different "redundant" 
> semantic models is actually a *design goal* of Swift?  For example:
> Value semantics vs reference semantics
> Pass-by-owned vs pass-by-shared vs pass-by-reference parameters
> dynamic dispatch vs static dispatch
> associatedtype vs generics
> "complete" types (e.g. Array) vs  "incomplete" types (Sequence) and 
> which one is permitted after a colon
> strong vs weak vs unowned

It isn’t the fact that there are multiple models, but they way those models 
interact with each other in the brain.  You can actually have lots of different 
models without causing confusion, as long as the models fit well together.  It 
also isn’t the number of access levels that is a problem.  For example, you can 
have a ton of shirt sizes (XS, S, M, L, XL, XXL, 3XL) and it doesn’t cause more 
confusion as you add more sizes because they don’t conflict with one another.

A big part of the issue with our current access scheme is how similar the 
concepts are without being the same.  That is then made worse by the fact that 
they have been given similar names.

Note also that your list above is a list of typical stumbling blocks for new 
programmers in most languages. Swift has actually done a remarkable job with 
most of these through careful design of the way that they are framed / exposed 
to the programmer.  In general, these things are well separated from each 
other.  For example, associatedtype and generics have completely different 
syntax.  Still, each of the above features comes with a significant mental 
cost.  We are willing to pay that cost because of how useful the distinction is.

Do you feel that allowing both scoped private & file-based private is actually 
important enough to warrant the significant design work it would take to bring 
it up to par with these other features?  It is not impossible, but it really 
doesn’t feel worth the effort to me (say compared to using that 
time/energy/thought to check off features from the generics manifesto).

> I would argue that supporting whatever the programmer's chosen mental model 
> is actually Swift's greatest strength.  We could have a language with only 
> reference types for example, it would be far, far simpler and easier to 
> teach.  I am glad that we don't have that language.  I don't use all of these 
> in every program, but I use all of them eventually, and each one is right for 
> some situation.
> 
> Many of us don't know half these models half as as well as we'd like.  But we 
> also like less than half of them half as well as they deserve.  Visibility is 
> in line with the trend here.

I disagree that supporting any mental model is a goal of Swift (or even 
something that it does).  In general, Swift is an opinionated language, which 
means just the opposite.

>>> Of the three, I am personally most supportive of file-based
> 
> My concern about dropping down to file-based is it doesn't allow any nesting, 
> which isn't powerful enough for several examples posted in this discussion.  
> Unless by "file-based" we mean "directory-based" which is another proposal 
> that has seen strong opposition from the "it's too complicated" wing.

By file-based, I mean that visibility is thought of in units of file.  That 
might be a single file or a collection of files, but it would never be part of 
a file.

You could potentially still have nesting with file-based access, if we feel 
that is a desirable trait when we design submodules.  The boundaries would just 
still be in units of file.  The main question there is whether the power is 
worth the added complexity.

…or we could unify under a scope or type based access system, which would have 
different strengths and weaknesses.  But by trying to be all things to all 
people we are just ending up with a muddled mess.

Thanks,
Jon

> On March 24, 2017 at 5:00:33 AM, Jonathan Hull via swift-evolution 
> (swift-evolution@swift.org ) wrote:
> 
>> 
>> Several people have asked:  What is the harm it causes?
>> 
>> I would like to provide a (hopefully) clear answer to that.
>> 
>> There are a couple of problems with the design which are causing Cognitive 
>> Dissonance:
>> 
>> 1) Private & fileprivate require very different mental models to operate them
>> 2) They are named very similarly to each other
>> 3) There is a third concept of “private to the type” which requires a third 
>> mental model, but is spelled the same way in other languages 
>> 
>> Any 

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Ian Keen via swift-evolution]

I missed the other code based modules conversation floating around... this 
would also be a much better solution imo - dropping fileprivate and having 
modules with open/public/internal/private seems like it would cover everything 
one might need without being bound to something like a physical file..

/shrug

 
> In terms of black and white, approve or don't approve - I agree with Matt, 
> thumbs down on this one from me too.
> 
> For what it's worth while I also use fileprivate a lot I dislike the 
> concept... I think pairing scope to something physical like a file is weird - 
> but I also believe it is a symptom of a flaw in the tooling.
> 
> If Xcode supported module/framework based development as easily as IDEs like 
> visual studio then fileprivate would never have been needed and internal 
> scope would actually serve a purpose. We would have 'internal' types that can 
> live in their own files but would be invisible to the consumer of the 
> module/framework.
> 
> _That_ would be my hope for access modifiers going forward, but unless Xcode 
> is open sourced I fear that we have to make language compromises like 
> fileprivate which as essentially a crutch imo.
> 
> Ian Keen.

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

> On Mar 24, 2017, at 6:07 AM, Goffredo Marocchi  wrote:
> On Fri, Mar 24, 2017 at 9:59 AM, Jonathan Hull via swift-evolution 
> > wrote:
> 
> Several people have asked:  What is the harm it causes?
> 
> I would like to provide a (hopefully) clear answer to that.
> 
> There are a couple of problems with the design which are causing Cognitive 
> Dissonance:
> 
> 1) Private & fileprivate require very different mental models to operate them
> 2) They are named very similarly to each other
> 3) There is a third concept of “private to the type” which requires a third 
> mental model, but is spelled the same way in other languages 
> 
> Any one of these would cause confusion.  All of them together mean that even 
> those of us who understand how they work are bothered by them on a 
> subconscious level (similar to how misaligned graphics will give everyone a 
> subconscious feeling that a graphic design is “off” even if they can’t 
> discern why consciously).  Even many of those who are arguing to keep private 
> have argued to rename things or to make it work in a more type-based way by 
> extending visibility to extensions.  I don’t think anyone is denying there is 
> a problem here with the status quo.
> 
> There is a general rule in design that things that look similar (or in this 
> case are named similarly) need to behave similarly to avoid causing confusion 
> (and conversely things that behave differently *need* to look different).
> 
> **This is not something that will go away simply by learning the behavior.  
> It will continue to be a rough spot in the language that causes discomfort 
> until the underlying design issue is fixed.**
> 
> The ideal solution here would be to choose a single model and make everything 
> coherent under that.  We choose either file-based, scope-based, or type-based 
> access control and unify under that.
> 
> Why would this be the ideal solution? I tend to disagree and I do not think 
> there is real agreement or even anything approaching consensus that it would 
> be ideal... it feels quite restrictive.


My goal was to explain the cognitive psychology of why this is an issue so we 
can work together on solving the underlying causes (as opposed to making random 
changes until something feels right)

As I said above, the names are not the only issue causing the problem.  It is 
how the concepts interact in your brain.  They are locally consistent, but 
globally inconsistent. Basically, you look at one of them, and it makes sense, 
but when you try to consider both of them at once, it doesn’t quite fit.  The 
fact that it is close makes it worse, because your brain wants to make it fit 
(just as it keeps trying and failing with the optical illusion I posted that 
has the same issue).  The end result is that it causes cognitive dissonance, or 
a subconscious uneasy feeling caused by two incompatible mental models.

It isn’t just a naming or education issue.  That is why, when we were 
bikeshedding names, we couldn’t find any set of names that felt right.  Solving 
only issue 2 by renaming them to be different would still help a little, but it 
isn’t ideal because it only solves one of the underlying issues.

The reason picking one model and declaring it the winner is ideal, is that it 
gets rid of the actual cause of our problem.  

Even with this proposal, we would still have some negative transfer from other 
languages (expecting ‘private’ to behave based on how it has been experienced 
in other languages). Luckily, negative transfer is something that can be solved 
with training/education… even if it means learning is more difficult. We could 
potentially get rid of all 3 issues by getting rid of the word ‘private’ 
entirely as well, and calling fileprivate ‘local’ or something like that.  
Local would have the connotation that things nearby could see it.

Thanks,
Jon

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

[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Ian Keen via swift-evolution]

In terms of black and white, approve or don't approve - I agree with Matt, 
thumbs down on this one from me too.

For what it's worth while I also use fileprivate a lot I dislike the concept... 
I think pairing scope to something physical like a file is weird - but I also 
believe it is a symptom of a flaw in the tooling.

If Xcode supported module/framework based development as easily as IDEs like 
visual studio then fileprivate would never have been needed and internal scope 
would actually serve a purpose. We would have 'internal' types that can live in 
their own files but would be invisible to the consumer of the module/framework.

_That_ would be my hope for access modifiers going forward, but unless Xcode is 
open sourced I fear that we have to make language compromises like fileprivate 
which as essentially a crutch imo.

Ian Keen.


> I would like to separately concur with (most of) Matt's excellent review.He 
> identifies what I think the core issues here, which are
> People code in different styles.A scoped keyword is more useful in some 
> styles and less useful in others, and this debate is in many ways a proxy war 
> about programming style.
> Most of the "solutions" proposed boil down to telling private users to adopt 
> a different programming style.Instead we should be making Swift a great 
> language for a *wider* diversity of programming styles as it expands to new 
> platforms and solves new problems.
> The complexity argument seems weak or even absent.It consists largely of the 
> informal observation that 3 keywords are better than 4, which may "feel true" 
> but does not have the research behind it of a Goto Considered 
> Harmful™.Instead, most of the research on usage and impact are coming from 
> those trying to keep it, which does not seem like their burden to meet.
> On March 23, 2017 at 1:22:49 AM, Matt Gallagher via swift-evolution 
> (swift-evolution at swift.org) wrote:
> 
> > What is your evaluation of the proposal?
> I disagree with this proposal. It removes functionality that I actively use.
> 
> This proposal aims to revert SE-0025 without really addressing the aims of 
> that proposal, merely dismissing the result as "actively harmful" without 
> defining what that means. SE-0159 raises the complaint that "private" is 
> syntactically more natural default while "fileprivate" is a more useful 
> default. On this point, I agree but the proposal is not about mere renaming.
> 
> The other discussion in the proposal is to ask the questions:
> 
> 1. is that distinction between private and fileprivate actively used by the 
> larger community of Swift developers
> 
> 2. if it were used pervasively, would it be worth the cognitive load and 
> complexity of keeping two very similar access levels in the language?
> 
> Fair questions but despite the proposal claiming "This proposal argues that 
> answer to both questions is no", the proposal offers no *arguments* for the 
> answers, it merely states a position.
> 
> For this reason, I feel the proposal is unreasonably dismissive of the aims 
> of SE-0025.
> 
> Frankly, both these questions have subjective answers based on how 
> programmers tend to design their programs. I personally like to build 
> functionality using lots of very tiny types (many just 4 or 5 lines long), 
> therefore, I frequently put multiple types in the same file (they're part of 
> the same functionality, even if they're not part of the same type). However, 
> I want to have actual interfaces and implementation hiding between them 
> otherwise there's always the possibility of accidentally abusing the 
> interface to each type. An access modifier narrower than the file, like the 
> current scoped "private", is the *only* way to achieve this.
> 
> Reverting SE-0025 means the only way to have enforced interfaces between 
> types is to place them in separate files. This is counterproductive for tiny 
> types that form a single conceptual entity. Separate files also requires 
> whole-program optimization for optimal performance.
> 
> The only conclusion I can make is that programmers in favor of this proposal 
> simply don't program this way. However, I find it insulting that this 
> proposal is essentially saying: your way of designing and structuring 
> programs is wrong; you must use big monolithic types in their own files and 
> endure reduced compilation (whole-program optimization) or runtime 
> performance (no inlining between files with whole-program off).
> 
> I can't help but feel that this proposal is really misdirected frustration. 
> Programmers who don't use clusters of tiny types in a single file shouldn't 
> care about the existence of a scoped access modifier because it shouldn't 
> affect them – they should use file access modifiers and be done. Yet 
> apparently, it is file access modifier advocates pushing this proposal.
> 
> It really seems like the existence of a scoped access modifier is taking the 
> blame for people's frustration that 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Michael Ilseman via swift-evolution]

-1

While I believe that "fileprivate is the one true private" and was opposed to 
how SE-0025 turned out, this doesn’t fix access control. It introduces language 
churn without a replacement solution during a time when source compatibility is 
very important. The cognitive retraining price was paid in Swift 3, and even if 
that was a mistake it doesn’t justify forcing everyone to pay it again, 
especially those who are now adopting a more stable and mature language 
compared to Swift 2. That price is better paid when there’s a replacement, e.g. 
some comprehensive redesign or submodules.



> On Mar 20, 2017, at 4:54 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs through 
> March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>  
> 
> Reply text
> Other replies
>  
> What
>  goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Vinnie Hesener via swift-evolution]

I agree it would be hard. In fact, it would be the most difficult part
about it. Like how the API team at Apple will debate for weeks the name of
a foundation method.

Another counter point to my theory is that most developers will go for the
automatic "private var". So there would definitely be a habitual ritual
learning curve. But imagine how much more accurate and descriptive it would
be for new folks. And Crustys (like me) can claim a terse semantic victory,
although having to relearn some mental autopilot routines.


On Fri, Mar 24, 2017 at 9:42 AM Sean Heber  wrote:

> This line of thought seems worth some consideration - why require a mental
> mapping from the meaning of “public” to what it *really* is when it could
> just say what it means? Although I admit that coming up with decent words
> or nice phrasings might be harder than it seems. :)
>
> l8r
> Sean
>
>
> > On Mar 24, 2017, at 6:12 AM, Vinnie Hesener via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I like the idea of changing some reserved words. Aren't 'private',
> 'friend, 'public', 'internal', etc just metaphors that were built on top of
> object encapsulation (another metaphor)? I think we're starting to see the
> limits of stretching metaphoric syntax.
> >
> > Why can't we just start naming access modifiers literally: a location in
> the code that they apply to. Examples such as "scope" or
> "insidethecurlybraces" or "file" or "module" or "submodule" or "codebase".
> Any of these or other synonyms would be much more Swifty in my opinion.
> > ___
> > 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] [Review] SE-0159: Fix Private Access Levels

[Daniel Duan via swift-evolution]

> What is your evaluation of the proposal?
-1
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Here lies the core reason for my down vote. There are currently 3541 
occurrences of 'private' and 635 'fileprivate' in the code base I work on 
regularly. Without commenting on the merits and shortcomings of Swift 3's 
access control, these stats tells us 2 things:

1. This proposal is going to affect projects greatly. Not just in the sense of 
source incompatibility, but also the existing organization of code units given 
'private' exists as of today.
2. The "complexity" many has mentioned here is largely a non-problem (we 
managed to use a lot of both, and I submit they are used appropriately).

The barrier for breaking change at this scale for Swift 4 should be *very* 
high. The proposal as-is doesn't include enough convincing argument to meet 
such standard.
> Does this proposal fit well with the feel and direction of Swift?
Perhaps.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I'm familiar with at least Swift 2 :)
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Read the text of proposal, all discussions on list (current and past), and a 
bunch of exchanges on Twitter.

---
IMHO, access control, modules (or any type of compiler enforced namespacing), 
and a more advanced importing syntax are closely interconnected. Whoever 
proposes to change one of these should have a clear picture of how the change 
would affect the other two area and include it in the text. In fact, I would 
like to see one proposal or manifesto that address them all together. The 
approach of "fix it now and think about the rest later" just puts more 
constraints on design of "the rest", in addition to making it possible that 
access control needs to be tweaked even more in future versions of Swift.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 24, 2017, at 11:53 AM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
> 
>> On March 24, 2017 at 11:46:00 AM, Charles Srstka (cocoa...@charlessoft.com) 
>> wrote:
>> 
 On Mar 24, 2017, at 11:41 AM, Drew Crawford via swift-evolution 
  wrote:
>>> 
>>> I would argue that supporting whatever the programmer's chosen mental model 
>>> is actually Swift's greatest strength.  We could have a language with only 
>>> reference types for example, it would be far, far simpler and easier to 
>>> teach.  I am glad that we don't have that language.
>> 
>> We kinda do, though, or did, in Objective-C (well, the “Objective” parts of 
>> it, anyway).
>> 
>> Charles
>> 
> 
> Exactly.  I mean the same people who brought us ObjC decided we needed a 
> language with multiple mental models.  They could have shipped reference 
> types only, they shipped value types on day 1.  To me there is no clearer 
> plank in the platform than that.
> 
> If you like your ObjC, you can keep it.  Swift exists exactly because we 
> reject some (not all) of the ObjC way, and it's not just syntax.  One of the 
> things rejected is There Should Be One Way To Do It™.  Swift embraces many 
> ways to write your program and has from 1.0.

+1.  I love this aspect of Swift.  It lets me choose the tool and model best 
suited to each specific task.

> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 11:46:00 AM, Charles Srstka (cocoa...@charlessoft.com) 
wrote:

On Mar 24, 2017, at 11:41 AM, Drew Crawford via swift-evolution 
 wrote:

I would argue that supporting whatever the programmer's chosen mental model is 
actually Swift's greatest strength.  We could have a language with only 
reference types for example, it would be far, far simpler and easier to teach.  
I am glad that we don't have that language.

We kinda do, though, or did, in Objective-C (well, the “Objective” parts of it, 
anyway).

Charles


Exactly.  I mean the same people who brought us ObjC decided we needed a 
language with multiple mental models.  They could have shipped reference types 
only, they shipped value types on day 1.  To me there is no clearer plank in 
the platform than that.

If you like your ObjC, you can keep it.  Swift exists exactly because we reject 
some (not all) of the ObjC way, and it's not just syntax.  One of the things 
rejected is There Should Be One Way To Do It™.  Swift embraces many ways to 
write your program and has from 1.0.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 24, 2017, at 11:41 AM, Drew Crawford via swift-evolution 
>  wrote:
> 
> I would argue that supporting whatever the programmer's chosen mental model 
> is actually Swift's greatest strength.  We could have a language with only 
> reference types for example, it would be far, far simpler and easier to 
> teach.  I am glad that we don't have that language.

We kinda do, though, or did, in Objective-C (well, the “Objective” parts of it, 
anyway).

Charles

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

There are a couple of problems with the design which are causing Cognitive 
Dissonance:

1) Private & fileprivate require very different mental models to operate them
2) They are named very similarly to each other
3) There is a third concept of “private to the type” which requires a third 
mental model, but is spelled the same way in other languages 

How would you respond to the allegation that supporting different "redundant" 
semantic models is actually a *design goal* of Swift?  For example:
Value semantics vs reference semantics
Pass-by-owned vs pass-by-shared vs pass-by-reference parameters
dynamic dispatch vs static dispatch
associatedtype vs generics
"complete" types (e.g. Array) vs  "incomplete" types (Sequence) and which 
one is permitted after a colon
strong vs weak vs unowned
I would argue that supporting whatever the programmer's chosen mental model is 
actually Swift's greatest strength.  We could have a language with only 
reference types for example, it would be far, far simpler and easier to teach.  
I am glad that we don't have that language.  I don't use all of these in every 
program, but I use all of them eventually, and each one is right for some 
situation.

Many of us don't know half these models half as as well as we'd like.  But we 
also like less than half of them half as well as they deserve.  Visibility is 
in line with the trend here.

Of the three, I am personally most supportive of file-based


My concern about dropping down to file-based is it doesn't allow any nesting, 
which isn't powerful enough for several examples posted in this discussion.  
Unless by "file-based" we mean "directory-based" which is another proposal that 
has seen strong opposition from the "it's too complicated" wing.


On March 24, 2017 at 5:00:33 AM, Jonathan Hull via swift-evolution 
(swift-evolution@swift.org) wrote:


Several people have asked:  What is the harm it causes?

I would like to provide a (hopefully) clear answer to that.

There are a couple of problems with the design which are causing Cognitive 
Dissonance:

1) Private & fileprivate require very different mental models to operate them
2) They are named very similarly to each other
3) There is a third concept of “private to the type” which requires a third 
mental model, but is spelled the same way in other languages 

Any one of these would cause confusion.  All of them together mean that even 
those of us who understand how they work are bothered by them on a subconscious 
level (similar to how misaligned graphics will give everyone a subconscious 
feeling that a graphic design is “off” even if they can’t discern why 
consciously).  Even many of those who are arguing to keep private have argued 
to rename things or to make it work in a more type-based way by extending 
visibility to extensions.  I don’t think anyone is denying there is a problem 
here with the status quo.

There is a general rule in design that things that look similar (or in this 
case are named similarly) need to behave similarly to avoid causing confusion 
(and conversely things that behave differently *need* to look different).

**This is not something that will go away simply by learning the behavior.  It 
will continue to be a rough spot in the language that causes discomfort until 
the underlying design issue is fixed.**

The ideal solution here would be to choose a single model and make everything 
coherent under that.  We choose either file-based, scope-based, or type-based 
access control and unify under that.

For file-based, that means that our sub-modules, when we add them, would need 
to be file-based as well.

If we choose Scope-based, then it really cries out for some sort of 
parameterized private.  That is you only have private and public, but for 
private you would be able to name a scope to widen the visibility to the named 
scope.  Submodules would then need to be scope based, and you would probably 
use the parameterized private with the submodule name to share data within it.

Type-based is very common in other languages, but I fear it would not play 
nicely with the way Swift has grown to work.  The pros are that you could 
access private variables from extensions, but getting types to work together 
with the ease they do now would require a lot of design work (and may not even 
be quite possible).  You also have additional complexities around subtypes, 
etc...


We really need to choose a single direction and not mix and match.

Of the three, I am personally most supportive of file-based because it is the 
closest to where we are now, and it seems to simplify many of the concerns 
about “friend” types by having visibility be dependent on proximity… which 
seems very intuitive to me.

As I said before, my preference would be to tentatively accept the change, but 
delay implementation until we design submodules for Swift 5. That way the 
design can be more cohesive as we can tackle it all at once.  If submodules 
won’t be in scope until after 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Alan Westbrook via swift-evolution]

What is your evaluation of the proposal?
Strongly in favor: +1


Is the problem being addressed significant enough to warrant a change to Swift?
Having to deal with the fallout from the original proposal every day, I would 
say yes.


Does this proposal fit well with the feel and direction of Swift?
For the long term evolution and philosophy of the language, I believe this is a 
positive change.


If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I’m not sure a comparison is apt in this case, the point of Swift is to be 
better, you can’t be better and be the same.


How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
Merely personal anecdotal experience with some large codebases that have taken 
to de facto writing `fileprivate` for everything as the current `private` 
appears to be too persnickety to use in the general case.


___
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] [Review] SE-0159: Fix Private Access Levels

[Joshua Alvarado via swift-evolution]

-1 as this is just another keyword change and removing the keyword does not
bring more benefit to Swift as the fileprivate keyword gives currently.

Fileprivate makes sense because creating extensions on objects in the same
file is a heavily used feature in Swift. It is very common for
implementing protocol adherence. Sometimes those properties in the original
class you don't want to give to those extensions in the same file or other
objects in the same file. Maybe proposing a rename can be beneficial to
help with the "cognitive load" but it will be the same argument as renaming
the guard keyword, it just doesn't bring enough benefit. Also Private and
fileprivate makes sense. Not much to think about. Private is completely
closed off and fileprivate is private to others outside the file so other
classes, structs, or objects may reside it in it as well and the properties
can be shared among (which is common to do).

On Mon, Mar 20, 2017 at 5:54 PM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
> through March 27, 2017. The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0159-fix-private-access-levels.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0159-fix-private-access-levels.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>- Does this proposal fit well with the feel and direction of Swift?
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug
>
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
Joshua Alvarado
alvaradojosh...@gmail.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Sean Heber via swift-evolution]

This line of thought seems worth some consideration - why require a mental 
mapping from the meaning of “public” to what it *really* is when it could just 
say what it means? Although I admit that coming up with decent words or nice 
phrasings might be harder than it seems. :)

l8r
Sean


> On Mar 24, 2017, at 6:12 AM, Vinnie Hesener via swift-evolution 
>  wrote:
> 
> I like the idea of changing some reserved words. Aren't 'private', 'friend, 
> 'public', 'internal', etc just metaphors that were built on top of object 
> encapsulation (another metaphor)? I think we're starting to see the limits of 
> stretching metaphoric syntax.
> 
> Why can't we just start naming access modifiers literally: a location in the 
> code that they apply to. Examples such as "scope" or "insidethecurlybraces" 
> or "file" or "module" or "submodule" or "codebase". Any of these or other 
> synonyms would be much more Swifty in my opinion. 
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 24, 2017, at 12:32 AM, Rien  wrote:
> 
> 
>>> On 23 Mar 2017, at 21:26, Jose Cheyo Jimenez  wrote:
>>> 
>>> 
>>> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 21 Mar 2017, at 08:05, Rien  wrote:
 
 +1
>>> 
>>> -1: I have revised my opinion.
>>> 
>>> 
 
>• What is your evaluation of the proposal?
 
 Makes the language easier to understand, lowers cognitive load during 
 coding.
 I also hope this will pave the way for a overhaul of the access level 
 system including modularization.
>>> 
>>> I still hope that fileprivate will be dumped one day. Presumably when a 
>>> better proposal is on the table.
>>> However it is clear that for some people the disadvantage of dropping it 
>>> now is bigger than the advantage to the proponents together.
>>> Regardless of wether the need is only perceived or not.
>>> 
 
>• Is the problem being addressed significant enough to warrant a 
> change to Swift?
 
 yes.
>>> 
>>> yes, but not without an alternative solution in place at the time 
>>> fileprivate is dropped.
>> 
>> Can you clarify what you mean here? 
> 
> Quite obviously the functionality of the current private feature is part of 
> the workflow of a considerable number of people.
> It does not really matter if this feature is necessary or not, they have it 
> integrated in their thinking and workflow.
> (Note: we don’t need "for element in collection" either, plain "1..N" for 
> loops would suffice)
> To me, that is enough reason to postpone this proposal until this 
> functionality can be retained while at the same time reverting private back 
> to its original meaning.

That is alternative 3. 

> Rien.
> 
>> 
>>> 
>>> 
 
>• Does this proposal fit well with the feel and direction of Swift?
 
 Yes
>>> 
>>> Yes
>>> 
 
>• If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
 
 private vs fileprivate seems swift-only, as such I have no comparison.
>>> 
>>> Same
>>> 
 
>• How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
 
 Followed and participated in the discussions.
>>> 
>>> 
>>> Same.
>>> 
 
 
 Regards,
 Rien
 
 Site: http://balancingrock.nl
 Blog: http://swiftrien.blogspot.com
 Github: http://github.com/Balancingrock
 Project: http://swiftfire.nl
 
 
 
 
 
> On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of SE-0159 "Fix Private Access Levels" begins now and runs 
> through March 27, 2017. The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the 
> review manager. When replying, please try to keep the proposal link at 
> the top of the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction 
> of Swift. When writing your review, here are some questions you might 
> want to answer in your review:
> 
>• What is your evaluation of the proposal?
>• Is the problem being addressed significant enough to warrant a 
> change to Swift?
>• Does this proposal fit well with the feel and direction of Swift?
>• If you have used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?
>• How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> 

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 24, 2017, at 4:59 AM, Jonathan Hull  wrote:
> 
> 
> Several people have asked:  What is the harm it causes?
> 
> I would like to provide a (hopefully) clear answer to that.
> 
> There are a couple of problems with the design which are causing Cognitive 
> Dissonance:
> 
> 1) Private & fileprivate require very different mental models to operate them
> 2) They are named very similarly to each other
> 3) There is a third concept of “private to the type” which requires a third 
> mental model, but is spelled the same way in other languages 
> 
> Any one of these would cause confusion.  All of them together mean that even 
> those of us who understand how they work are bothered by them on a 
> subconscious level (similar to how misaligned graphics will give everyone a 
> subconscious feeling that a graphic design is “off” even if they can’t 
> discern why consciously).  Even many of those who are arguing to keep private 
> have argued to rename things or to make it work in a more type-based way by 
> extending visibility to extensions.  I don’t think anyone is denying there is 
> a problem here with the status quo.
> 
> There is a general rule in design that things that look similar (or in this 
> case are named similarly) need to behave similarly to avoid causing confusion 
> (and conversely things that behave differently *need* to look different).
> 
> **This is not something that will go away simply by learning the behavior.  
> It will continue to be a rough spot in the language that causes discomfort 
> until the underlying design issue is fixed.**
> 
> The ideal solution here would be to choose a single model and make everything 
> coherent under that.  We choose either file-based, scope-based, or type-based 
> access control and unify under that.

All of Swift's access modifiers are already scope-based.  Files and modules 
form scopes.  Maybe this concept is new to a lot of people, but it is not 
internally inconsistent and does not make it a bad design.  I do agree that the 
current names are not great.

> 
> For file-based, that means that our sub-modules, when we add them, would need 
> to be file-based as well.
> 
> If we choose Scope-based, then it really cries out for some sort of 
> parameterized private.  That is you only have private and public, but for 
> private you would be able to name a scope to widen the visibility to the 
> named scope.  Submodules would then need to be scope based, and you would 
> probably use the parameterized private with the submodule name to share data 
> within it.
> 
> Type-based is very common in other languages, but I fear it would not play 
> nicely with the way Swift has grown to work.  The pros are that you could 
> access private variables from extensions, but getting types to work together 
> with the ease they do now would require a lot of design work (and may not 
> even be quite possible).  You also have additional complexities around 
> subtypes, etc...
> 
> 
> We really need to choose a single direction and not mix and match.
> 
> Of the three, I am personally most supportive of file-based because it is the 
> closest to where we are now, and it seems to simplify many of the concerns 
> about “friend” types by having visibility be dependent on proximity… which 
> seems very intuitive to me.
> 
> As I said before, my preference would be to tentatively accept the change, 
> but delay implementation until we design submodules for Swift 5. That way the 
> design can be more cohesive as we can tackle it all at once.  If submodules 
> won’t be in scope until after Swift 5, then we should implement the change 
> now.
> 
> I hope that explanation was at least a bit helpful…
> 
> Thanks,
> Jon
> 
> Technical note:  For the curious, basically we have made a design which is 
> "locally consistent, but globally inconsistent".  That is why the effect 
> doesn’t go away after learning the concepts involved.  Basically we have made 
> the programming equivalent of the following image:
> 
> https://upload.wikimedia.org/wikipedia/commons/7/7f/Impossible.png
>  
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 24, 2017, at 6:11 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> `scoped` was the name originally proposed in SE-0025, changed by the core 
> team on acceptance to `private`, and `file` was one of the suggestions for 
> what used to be called `private`; I remember because I suggested it too; it 
> was renamed to `fileprivate` after consideration of this alternative.

I believe the original proposal actually used `local` which I thought was not a 
good name.  `scoped` didn't receive significant discussion (any that I recall) 
until after Swift 3 was already released.

> 
> 
>> On Fri, Mar 24, 2017 at 5:27 AM, Vinnie Hesener via swift-evolution 
>>  wrote:
>> This discussion escalated real quickly. There are some very bright minds in 
>> the mud right now, but I think there may still be a way to salvage this 
>> discussion. 
>> 
>> Chris talked about there being two layers to Swift... the easy mode for 
>> adoption and outreach, then the advanced mode for taking over the world. 
>> This requires a delicate balance of features vs usability (e.g. MS Paint vs 
>> Photoshop). There are various ways to approach that balance, but they almost 
>> always require creativity and cooperation from the smartest guys in the room.
>> 
>> I'm not one of those guys, but let me throw out some food for thought. Is 
>> there a way to not only please both generalized arguments, but also solve 
>> the root of the problem? For instance, has anyone thought about why we even 
>> call things public, private, etc? Other than their initial meaning, the 
>> answer may be "other languages do it" or even better "that is what prevents 
>> confusion and dupe questions on stackoverflow". Fair enough.
>> 
>> I realize this would be jolting for most, but would anyone be asking the 
>> stackoverflow ether what a **scope** var was? How about a **file** func? How 
>> about a SO title: "What does **module** let myVar refer to?" 
>> 
>> Don't we have the opportunity to offer, within reason, a large set of 
>> accessors that are self explanatory? I think it may solve the complexity for 
>> usefulness exchange because they are simply there for the advanced users 
>> that want to use them. There's no choosing for newbs because the choice is 
>> in the name, assuming we name them pristinely (I have faith!). 
>> 
>> I'm also a little cooky too, but maybe this can spark some creativity in a 
>> more wholistic solution for both sides. 
>>  
>> 
>> > Hello Swift community,
>> > 
>> > The review of SE-0159 "Fix Private Access Levels" begins now and runs 
>> > through March 27, 2017. The proposal is available here:
>> > 
>> > https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> > Reviews are an important part of the Swift evolution process. All reviews 
>> > should be sent to the swift-evolution mailing list at
>> > 
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> > or, if you would like to keep your feedback private, directly to the 
>> > review manager. When replying, please try to keep the proposal link at the 
>> > top of the message:
>> > 
>> > Proposal link:
>> > 
>> > https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
>> > Reply text
>> > Other replies
>> > What
>> >  goes into a review?
>> > 
>> > The goal of the review process is to improve the proposal under review 
>> > through constructive criticism and, eventually, determine the direction of 
>> > Swift. When writing your review, here are some questions you might want to 
>> > answer in your review:
>> > 
>> > What is your evaluation of the proposal?
>> > Is the problem being addressed significant enough to warrant a change to 
>> > Swift?
>> > Does this proposal fit well with the feel and direction of Swift?
>> > If you have used other languages or libraries with a similar feature, how 
>> > do you feel that this proposal compares to those?
>> > How much effort did you put into your review? A glance, a quick reading, 
>> > or an in-depth study?
>> > More information about the Swift evolution process is available at
>> > 
>> > https://github.com/apple/swift-evolution/blob/master/process.md
>> > Thank you,
>> > 
>> > -Doug
>> > 
>> > Review Manager
>> > 
>> > 
>> >
>> 
>> ___
>> 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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Zach Waldowski via swift-evolution]

On Fri, Mar 24, 2017, at 05:59 AM, Jonathan Hull via swift-evolution wrote:
> **This is not something that will go away simply by learning the
> behavior.  It will continue to be a rough spot in the language that
> causes discomfort until the underlying design issue is fixed.**


I want to keep repeating this statement from Jonathan until someone
actually pays attention to it. The impedance mismatch between the access
levels is not simply programmer flavor. It  taints the basic nature of
learning Swift, and learning those different styles.


I want to be open to other programming styles, and would be interested
in using the one that so desperately "needs" scope private as people on
this thread claim. Except I'm turned off it immediately by having to
accommodate this jagged, ugly, bleeding edge of the language.


Best,

  Zachary Waldowski

  z...@waldowski.me




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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

`scoped` was the name originally proposed in SE-0025, changed by the core
team on acceptance to `private`, and `file` was one of the suggestions for
what used to be called `private`; I remember because I suggested it too; it
was renamed to `fileprivate` after consideration of this alternative.


On Fri, Mar 24, 2017 at 5:27 AM, Vinnie Hesener via swift-evolution <
swift-evolution@swift.org> wrote:

> This discussion escalated real quickly. There are some very bright minds
> in the mud right now, but I think there may still be a way to salvage this
> discussion.
>
> Chris talked about there being two layers to Swift... the easy mode for
> adoption and outreach, then the advanced mode for taking over the world.
> This requires a delicate balance of features vs usability (e.g. MS Paint vs
> Photoshop). There are various ways to approach that balance, but they
> almost always require creativity and cooperation from the smartest guys in
> the room.
>
> I'm not one of those guys, but let me throw out some food for thought. Is
> there a way to not only please both generalized arguments, but also solve
> the root of the problem? For instance, has anyone thought about why we even
> call things public, private, etc? Other than their initial meaning, the
> answer may be "other languages do it" or even better "that is what prevents
> confusion and dupe questions on stackoverflow". Fair enough.
>
> I realize this would be jolting for most, but would anyone be asking the
> stackoverflow ether what a **scope** var was? How about a **file** func?
> How about a SO title: "What does **module** let myVar refer to?"
>
> Don't we have the opportunity to offer, within reason, a large set of
> accessors that are self explanatory? I think it may solve the complexity
> for usefulness exchange because they are simply there for the advanced
> users that want to use them. There's no choosing for newbs because the
> choice is in the name, assuming we name them pristinely (I have faith!).
>
> I'm also a little cooky too, but maybe this can spark some creativity in a
> more wholistic solution for both sides.
>
>
> > Hello Swift community,
> >
> > The review of SE-0159 "Fix Private Access Levels" begins now and runs
> through March 27, 2017. The proposal is available here:
> >
> > https://github.com/apple/swift-evolution/blob/master/
> proposals/0159-fix-private-access-levels.md
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >
> > https://lists.swift.org/mailman/listinfo/swift-evolution<
> https://lists.swift.org/mailman/listinfo/swift-evolution>
> > or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
> >
> > Proposal link:
> >
> > https://github.com/apple/swift-evolution/blob/master/
> proposals/0159-fix-private-access-levels.md
> > Reply text
> > Other replies
> >  process.md#what-goes-into-a-review-1>What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
> >
> > What is your evaluation of the proposal?
> > Is the problem being addressed significant enough to warrant a change to
> Swift?
> > Does this proposal fit well with the feel and direction of Swift?
> > If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
> > How much effort did you put into your review? A glance, a quick reading,
> or an in-depth study?
> > More information about the Swift evolution process is available at
> >
> > https://github.com/apple/swift-evolution/blob/master/process.md<
> https://github.com/apple/swift-evolution/blob/master/process.md>
> > Thank you,
> >
> > -Doug
> >
> > Review Manager
> >
> >
> >
>
> ___
> 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] [Review] SE-0159: Fix Private Access Levels

[Vinnie Hesener via swift-evolution]

This discussion escalated real quickly. There are some very bright minds in
the mud right now, but I think there may still be a way to salvage this
discussion.

Chris talked about there being two layers to Swift... the easy mode for
adoption and outreach, then the advanced mode for taking over the world.
This requires a delicate balance of features vs usability (e.g. MS Paint vs
Photoshop). There are various ways to approach that balance, but they
almost always require creativity and cooperation from the smartest guys in
the room.

I'm not one of those guys, but let me throw out some food for thought. Is
there a way to not only please both generalized arguments, but also solve
the root of the problem? For instance, has anyone thought about why we even
call things public, private, etc? Other than their initial meaning, the
answer may be "other languages do it" or even better "that is what prevents
confusion and dupe questions on stackoverflow". Fair enough.

I realize this would be jolting for most, but would anyone be asking the
stackoverflow ether what a **scope** var was? How about a **file** func?
How about a SO title: "What does **module** let myVar refer to?"

Don't we have the opportunity to offer, within reason, a large set of
accessors that are self explanatory? I think it may solve the complexity
for usefulness exchange because they are simply there for the advanced
users that want to use them. There's no choosing for newbs because the
choice is in the name, assuming we name them pristinely (I have faith!).

I'm also a little cooky too, but maybe this can spark some creativity in a
more wholistic solution for both sides.


> Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution<
https://lists.swift.org/mailman/listinfo/swift-evolution>
> or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
>
> Proposal link:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text
> Other replies
> <
https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What
goes into a review?
>
> The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
>
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to
Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md<
https://github.com/apple/swift-evolution/blob/master/process.md>
> Thank you,
>
> -Doug
>
> Review Manager
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull via swift-evolution]

Several people have asked:  What is the harm it causes?

I would like to provide a (hopefully) clear answer to that.

There are a couple of problems with the design which are causing Cognitive 
Dissonance:

1) Private & fileprivate require very different mental models to operate them
2) They are named very similarly to each other
3) There is a third concept of “private to the type” which requires a third 
mental model, but is spelled the same way in other languages 

Any one of these would cause confusion.  All of them together mean that even 
those of us who understand how they work are bothered by them on a subconscious 
level (similar to how misaligned graphics will give everyone a subconscious 
feeling that a graphic design is “off” even if they can’t discern why 
consciously).  Even many of those who are arguing to keep private have argued 
to rename things or to make it work in a more type-based way by extending 
visibility to extensions.  I don’t think anyone is denying there is a problem 
here with the status quo.

There is a general rule in design that things that look similar (or in this 
case are named similarly) need to behave similarly to avoid causing confusion 
(and conversely things that behave differently *need* to look different).

**This is not something that will go away simply by learning the behavior.  It 
will continue to be a rough spot in the language that causes discomfort until 
the underlying design issue is fixed.**

The ideal solution here would be to choose a single model and make everything 
coherent under that.  We choose either file-based, scope-based, or type-based 
access control and unify under that.

For file-based, that means that our sub-modules, when we add them, would need 
to be file-based as well.

If we choose Scope-based, then it really cries out for some sort of 
parameterized private.  That is you only have private and public, but for 
private you would be able to name a scope to widen the visibility to the named 
scope.  Submodules would then need to be scope based, and you would probably 
use the parameterized private with the submodule name to share data within it.

Type-based is very common in other languages, but I fear it would not play 
nicely with the way Swift has grown to work.  The pros are that you could 
access private variables from extensions, but getting types to work together 
with the ease they do now would require a lot of design work (and may not even 
be quite possible).  You also have additional complexities around subtypes, 
etc...


We really need to choose a single direction and not mix and match.

Of the three, I am personally most supportive of file-based because it is the 
closest to where we are now, and it seems to simplify many of the concerns 
about “friend” types by having visibility be dependent on proximity… which 
seems very intuitive to me.

As I said before, my preference would be to tentatively accept the change, but 
delay implementation until we design submodules for Swift 5. That way the 
design can be more cohesive as we can tackle it all at once.  If submodules 
won’t be in scope until after Swift 5, then we should implement the change now.

I hope that explanation was at least a bit helpful…

Thanks,
Jon

Technical note:  For the curious, basically we have made a design which is 
"locally consistent, but globally inconsistent".  That is why the effect 
doesn’t go away after learning the concepts involved.  Basically we have made 
the programming equivalent of the following image:

https://upload.wikimedia.org/wikipedia/commons/7/7f/Impossible.png 

 

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

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Rien via swift-evolution]

> On 23 Mar 2017, at 21:26, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 21 Mar 2017, at 08:05, Rien  wrote:
>>> 
>>> +1
>> 
>> -1: I have revised my opinion.
>> 
>> 
>>> 
• What is your evaluation of the proposal?
>>> 
>>> Makes the language easier to understand, lowers cognitive load during 
>>> coding.
>>> I also hope this will pave the way for a overhaul of the access level 
>>> system including modularization.
>> 
>> I still hope that fileprivate will be dumped one day. Presumably when a 
>> better proposal is on the table.
>> However it is clear that for some people the disadvantage of dropping it now 
>> is bigger than the advantage to the proponents together.
>> Regardless of wether the need is only perceived or not.
>> 
>>> 
• Is the problem being addressed significant enough to warrant a change 
 to Swift?
>>> 
>>> yes.
>> 
>> yes, but not without an alternative solution in place at the time 
>> fileprivate is dropped.
> 
> Can you clarify what you mean here? 

Quite obviously the functionality of the current private feature is part of the 
workflow of a considerable number of people.
It does not really matter if this feature is necessary or not, they have it 
integrated in their thinking and workflow.
(Note: we don’t need "for element in collection" either, plain "1..N" for loops 
would suffice)
To me, that is enough reason to postpone this proposal until this functionality 
can be retained while at the same time reverting private back to its original 
meaning.

Rien.

> 
>> 
>> 
>>> 
• Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> Yes
>> 
>> Yes
>> 
>>> 
• If you have used other languages or libraries with a similar feature, 
 how do you feel that this proposal compares to those?
>>> 
>>> private vs fileprivate seems swift-only, as such I have no comparison.
>> 
>> Same
>> 
>>> 
• How much effort did you put into your review? A glance, a quick 
 reading, or an in-depth study?
>>> 
>>> Followed and participated in the discussions.
>> 
>> 
>> Same.
>> 
>>> 
>>> 
>>> Regards,
>>> Rien
>>> 
>>> Site: http://balancingrock.nl
>>> Blog: http://swiftrien.blogspot.com
>>> Github: http://github.com/Balancingrock
>>> Project: http://swiftfire.nl
>>> 
>>> 
>>> 
>>> 
>>> 
 On 21 Mar 2017, at 00:54, Douglas Gregor via swift-evolution 
  wrote:
 
 Hello Swift community,
 
 The review of SE-0159 "Fix Private Access Levels" begins now and runs 
 through March 27, 2017. The proposal is available here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
 Reviews are an important part of the Swift evolution process. All reviews 
 should be sent to the swift-evolution mailing list at
 
 https://lists.swift.org/mailman/listinfo/swift-evolution
 or, if you would like to keep your feedback private, directly to the 
 review manager. When replying, please try to keep the proposal link at the 
 top of the message:
 
 Proposal link:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
 Reply text
 Other replies
 What goes into a review?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. When writing your review, here are some questions you might want to 
 answer in your review:
 
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change 
 to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, 
 how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick 
 reading, or an in-depth study?
 More information about the Swift evolution process is available at
 
 https://github.com/apple/swift-evolution/blob/master/process.md
 Thank you,
 
 -Doug
 
 Review Manager
 
 ___
 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] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

I would like to separately concur with (most of) Matt's excellent review.  He 
identifies what I think the core issues here, which are
People code in different styles.  A scoped keyword is more useful in some 
styles and less useful in others, and this debate is in many ways a proxy war 
about programming style.
Most of the "solutions" proposed boil down to telling private users to adopt a 
different programming style.  Instead we should be making Swift a great 
language for a *wider* diversity of programming styles as it expands to new 
platforms and solves new problems.
The complexity argument seems weak or even absent.  It consists largely of the 
informal observation that 3 keywords are better than 4, which may "feel true" 
but does not have the research behind it of a Goto Considered Harmful™.  
Instead, most of the research on usage and impact are coming from those trying 
to keep it, which does not seem like their burden to meet.
On March 23, 2017 at 1:22:49 AM, Matt Gallagher via swift-evolution 
(swift-evolution@swift.org) wrote:

> What is your evaluation of the proposal?

I disagree with this proposal. It removes functionality that I actively use.

This proposal aims to revert SE-0025 without really addressing the aims of that 
proposal, merely dismissing the result as "actively harmful" without defining 
what that means. SE-0159 raises the complaint that "private" is syntactically 
more natural default while "fileprivate" is a more useful default. On this 
point, I agree but the proposal is not about mere renaming.

The other discussion in the proposal is to ask the questions:

1. is that distinction between private and fileprivate actively used by the 
larger community of Swift developers

2. if it were used pervasively, would it be worth the cognitive load and 
complexity of keeping two very similar access levels in the language?

Fair questions but despite the proposal claiming "This proposal argues that 
answer to both questions is no", the proposal offers no *arguments* for the 
answers, it merely states a position.

For this reason, I feel the proposal is unreasonably dismissive of the aims of 
SE-0025.

Frankly, both these questions have subjective answers based on how programmers 
tend to design their programs. I personally like to build functionality using 
lots of very tiny types (many just 4 or 5 lines long), therefore, I frequently 
put multiple types in the same file (they're part of the same functionality, 
even if they're not part of the same type). However, I want to have actual 
interfaces and implementation hiding between them otherwise there's always the 
possibility of accidentally abusing the interface to each type. An access 
modifier narrower than the file, like the current scoped "private", is the 
*only* way to achieve this.

Reverting SE-0025 means the only way to have enforced interfaces between types 
is to place them in separate files. This is counterproductive for tiny types 
that form a single conceptual entity. Separate files also requires 
whole-program optimization for optimal performance.

The only conclusion I can make is that programmers in favor of this proposal 
simply don't program this way. However, I find it insulting that this proposal 
is essentially saying: your way of designing and structuring programs is wrong; 
you must use big monolithic types in their own files and endure reduced 
compilation (whole-program optimization) or runtime performance (no inlining 
between files with whole-program off).

I can't help but feel that this proposal is really misdirected frustration. 
Programmers who don't use clusters of tiny types in a single file shouldn't 
care about the existence of a scoped access modifier because it shouldn't 
affect them – they should use file access modifiers and be done. Yet 
apparently, it is file access modifier advocates pushing this proposal.

It really seems like the existence of a scoped access modifier is taking the 
blame for people's frustration that the simpler keyword ("private") is a less 
good default than the clunky keyword ("fileprivate"). I personally agree that 
the behavior or "fileprivate" is probably a better default so I understand the 
desire to give "private" back that meaning again. However, I don't want to lose 
a scoped access modifier because it is *useful* (for reasons of both project 
structure and compilation or runtime performance).

So... thumbs down from me. However, if someone wants to rename fileprivate -> 
private and rename private -> scope (or something) I'd be more supportive.

Regards,
Matt Gallagher.

___
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] [Review] SE-0159: Fix Private Access Levels

[Carl Brown1 via swift-evolution]

Hello Swift community,
>
> The review of SE-0159 "Fix Private Access Levels" begins now and runs
through March 27, 2017. The proposal is available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution<
https://lists.swift.org/mailman/listinfo/swift-evolution>
> or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:
>
> Proposal link:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md
> Reply text

> What is your evaluation of the proposal?

-1. No.  Please don't remove a useful feature and break existing code in
thousands of places just to prevent some confusion due to the similarity of
two keywords.

> Is the problem being addressed significant enough to warrant a change to
Swift?

No. Not at all.

> Does this proposal fit well with the feel and direction of Swift?

No. This explicitly removes a feature that the community uses and takes us
back to Swift 2.2. That's literally the opposite of the "direction of
Swift".

> If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?

I've used a number of different languages with various scoping and access
modifiers, and there is enough variation in other languages that there's no
clear requirement that Swift should agree with any other languages' usage.

> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

I reviewed the usage of `private` and `fileprivate` in the
swift-corelibs-foundation and swift-corelibs-libdispatch repositories.
There are 500+ instances across those two repositories (386 private and 131
fileprivate on the version of those libraries I already had checked out on
my laptop to work on the bug I'm currently chasing).

To be honest, the open-source version of Foundation still has a long way to
go to get the level of quality of the existing Objective-C frameworks, and
we already have enough work to do without having to go make a bunch of
arbitrary changes and risk a bunch of regressions because someone doesn't
like a keyword.  This is a source-breaking change, and we need to stop
making source-breaking changes unless they're absolutely necessary, and
this is far from absolutely necessary.

Accepting this proposal would waste hundreds of person-hours of work and
cause even more confusion than it's trying to prevent by causing tons of
existing online documentation, tutorials and answered questions to be
rendered incorrect.

I vote "No".

-Carl

--
Carl Brown
Swift@IBM
carl.bro...@ibm.com (Work)
ca...@pobox.com (Home)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution