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

[Slava Pestov via swift-evolution]

How about private(world), public(module), internal(file)? :-)

Slava

> On Mar 25, 2017, at 4:15 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Please do not start a debate about `private(module)` which is equavalent to 
> `internal`, otherwise you could equally use a parametrized `public` for 
> everything. 
> 
> public(outside_module), public(only_inside_module), public(only_in_this_file) 
> or public(nowhere)
> 
> `internal` is just fine as it is.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> Am 25. März 2017 um 16:43:23, Matt Whiteside via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>>> On Mar 23, 2017, at 18:35, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> On Mar 23, 2017, at 8:27 PM, Drew Crawford >> > wrote:
>>> 
 
 The obvious example would be Rust.  Rust has exactly two visibilities, and 
 merely one keyword.  By default, members are "private" which is visible 
 inside the module (so, like Swift's internal). The "public" keyword is 
 similar to Swift. 
 
 The reason this works is that unlike in Swift where a module is something 
 like a library or framework (Rust calls those "crates"), in Rust modules 
 in are (explicitly) lexically scoped; a "mod myscope {}" module can be 
 created for the portion of the file for which the member should be visible 
 and it won't be visible outside that scope. Likewise, "fileprivate" can be 
 achieved by enclosing the file in a "mod MyFile {}". And like all lexical 
 scopes, they can be recursively nested to arbitrary depth to achieve any 
 number of visibility behaviors (e.g., declare a module for the first half 
 of two files) that would require complex new keywords to achieve in Swift. 
 Finally there are some shortcut features like the ability to infer a 
 module structure from the file system. 
>>> 
>>> This is a good example of what I meant.  There is an extremely broad range 
>>> of possible designs for submodules.  Some of them, such as this example, 
>>> would make it relatively easy to get by without fileprivate.  There are 
>>> also many other possible designs that would not.  
>> 
>> The Rust approach sounds ideal to me.  I hope Swift can get to this point 
>> some day.
>> 
>> But as for the current proposal, I’ve become convinced that it would cause 
>> headaches for too many people.  Parametrizing the private keyword seems a 
>> compromise between pragmatism and elegance:
>> 
>> public
>> private(module)
>> private(file)
>> private(scope)
>> 
>> -Matt
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Matt Whiteside via swift-evolution]

> On Mar 23, 2017, at 18:35, Matthew Johnson via swift-evolution 
>  wrote:
> 
> On Mar 23, 2017, at 8:27 PM, Drew Crawford  > wrote:
> 
>> 
>> The obvious example would be Rust.  Rust has exactly two visibilities, and 
>> merely one keyword.  By default, members are "private" which is visible 
>> inside the module (so, like Swift's internal). The "public" keyword is 
>> similar to Swift. 
>> 
>> The reason this works is that unlike in Swift where a module is something 
>> like a library or framework (Rust calls those "crates"), in Rust modules in 
>> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
>> for the portion of the file for which the member should be visible and it 
>> won't be visible outside that scope. Likewise, "fileprivate" can be achieved 
>> by enclosing the file in a "mod MyFile {}". And like all lexical scopes, 
>> they can be recursively nested to arbitrary depth to achieve any number of 
>> visibility behaviors (e.g., declare a module for the first half of two 
>> files) that would require complex new keywords to achieve in Swift. Finally 
>> there are some shortcut features like the ability to infer a module 
>> structure from the file system. 
> 
> This is a good example of what I meant.  There is an extremely broad range of 
> possible designs for submodules.  Some of them, such as this example, would 
> make it relatively easy to get by without fileprivate.  There are also many 
> other possible designs that would not.  

The Rust approach sounds ideal to me.  I hope Swift can get to this point some 
day.

But as for the current proposal, I’ve become convinced that it would cause 
headaches for too many people.  Parametrizing the private keyword seems a 
compromise between pragmatism and elegance:

public
private(module)
private(file)
private(scope)

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

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

[Robert Hedin via swift-evolution]

This would address my concerns.

rob


On Fri, Mar 24, 2017 at 10:27 AM, Ross O'Brien via swift-evolution <
swift-evolution@swift.org> wrote:

> We should be clear about this, because it seems to me that this is the
> source of the 'cognitive load' problem:
>
> Following Alternative 3,
> private properties in scopes, would become "scoped".
> fileprivate properties in or out of scopes would become "private".
> private types, such as protocols, classes, etc., would *stay* "private".
> The keyword would consistently mean private to the file, instead of
> changing its meaning at different scopes.
>
>
>
>
>
> On Fri, Mar 24, 2017 at 1:49 PM, Ricardo Parada via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> After reading the discussions it seems to me that renaming private ->
>> scoped and fileprivate -> private might keep both sides happy.
>>
>>
>>
>> > On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >> On 24.03.2017 11:47, Jonathan Hull via swift-evolution wrote:
>> >> Nevin had a fantastic proposal for submodules which changed private to
>> mean
>> >> “private to the submodule”, where each file was implicitly a submodule
>> >> unless you declared otherwise.  Simple and elegant.
>> >
>> > Currently I don't see how submodules can eliminate the needs of
>> 'scoped'(current 'private') access level. Even in submodule (even if
>> submodule will be a "namespace" line feature like "submodule Name{..}" and
>> we can have number of such declarations in the same file) - 'scoped' access
>> is valuable even for single type declaration. Probably I don't understand
>> something.
>> >
>> > But as for fileprivate - it is really logically to have it named
>> 'private' and it can naturally be used in submodules as "private to
>> submodule" just like "private to file" currently.
>> >
>> > So I do think the right move currently is to rename
>> fileprivate->private, private->scoped and then, when(if!) we have
>> submodules - we can change something.
>> > Rename will remove the huge confusion users(especially novice) have
>> with 'fileprivate' vs 'private'; experience shows that *actually*
>> programmers use 'fileprivate' a lot and this is some kind of Swift/iOs
>> programming style, and fileprivate is awkward keyword, and many(all? ;-)
>> just want 'private' means "in this file".
>> > Also novice programmer can know just about 'public', 'internal' and
>> 'private' - these three logically united access modifiers,all are
>> file-scoped, but more experienced programmer has no problems teach what
>> 'scoped' means and why one want to use it.
>> >
>> >>
>> >>
>> >>> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution
>> >>> > wrote:
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> Sent from my iPhone
>> >>> On Mar 23, 2017, at 6:41 PM, David Hart > >>> > wrote:
>> >>>
>>  I have difficulties imagining a submodule proposal that could allow
>> us
>>  to eliminate fileprivate. Care to give an example?
>> >>>
>> >>> The obvious example would be Rust.  Rust has exactly two visibilities,
>> >>> and merely one keyword.  By default, members are "private" which is
>> >>> visible inside the module (so, like Swift's internal). The "public"
>> >>> keyword is similar to Swift.
>> >>>
>> >>> The reason this works is that unlike in Swift where a module is
>> something
>> >>> like a library or framework (Rust calls those "crates"), in Rust
>> modules
>> >>> in are (explicitly) lexically scoped; a "mod myscope {}" module can be
>> >>> created for the portion of the file for which the member should be
>> >>> visible and it won't be visible outside that scope. Likewise,
>> >>> "fileprivate" can be achieved by enclosing the file in a "mod MyFile
>> {}".
>> >>> And like all lexical scopes, they can be recursively nested to
>> arbitrary
>> >>> depth to achieve any number of visibility behaviors (e.g., declare a
>> >>> module for the first half of two files) that would require complex new
>> >>> keywords to achieve in Swift. Finally there are some shortcut features
>> >>> like the ability to infer a module structure from the file system.
>> >>>
>> >>>
>> >>>
>> >>> In Swift, modules are presently tied to libraries/frameworks in a 1:1
>> >>> way. Because of this we lack the flexibility of recursively nestable
>> >>> modules of other languages and this is the underlying problem that
>> >>> motivates both scoped/private and fileprivate.  If we fixed that, we
>> >>> would actually not need either keyword.
>> >>>
>> >>> http://rustbyexample.com/mod/visibility.html
>> >>> https://doc.rust-lang.org/book/crates-and-modules.html
>> >>> ___
>> >>> swift-evolution mailing list
>> >>> swift-evolution@swift.org 
>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>
>> >>
>> >>
>> >> 

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

[David Sweeris via swift-evolution]

This and the reasons Drew laid out, are why I'm -1.

> On Mar 23, 2017, at 19:48, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> On Mar 23, 2017, at 8:27 PM, Drew Crawford  wrote:
>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
>>> 
 I have difficulties imagining a submodule proposal that could allow us to 
 eliminate fileprivate. Care to give an example?
>>> 
>>> The obvious example would be Rust.  Rust has exactly two visibilities, and 
>>> merely one keyword.  By default, members are "private" which is visible 
>>> inside the module (so, like Swift's internal). The "public" keyword is 
>>> similar to Swift. 
>>> 
>>> The reason this works is that unlike in Swift where a module is something 
>>> like a library or framework (Rust calls those "crates"), in Rust modules in 
>>> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
>>> for the portion of the file for which the member should be visible and it 
>>> won't be visible outside that scope. Likewise, "fileprivate" can be 
>>> achieved by enclosing the file in a "mod MyFile {}". And like all lexical 
>>> scopes, they can be recursively nested to arbitrary depth to achieve any 
>>> number of visibility behaviors (e.g., declare a module for the first half 
>>> of two files) that would require complex new keywords to achieve in Swift. 
>>> Finally there are some shortcut features like the ability to infer a module 
>>> structure from the file system. 
>> 
>> This is a good example of what I meant.  There is an extremely broad range 
>> of possible designs for submodules.  Some of them, such as this example, 
>> would make it relatively easy to get by without fileprivate.  There are also 
>> many other possible designs that would not.  
>> 
>> We do not have any idea where Swift will end up yet.  It's not reasonable to 
>> make any assumptions about what use cases the eventual design might or might 
>> not address.
> 
> Then why not leave private and fileprivate alone until we do?
> 
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 24, 2017 at 10:17:57 AM, Matt Whiteside (mwhiteside@gmail.com) 
wrote:

In other words, this use case seems fairly distant from what was intended for 
private vs fileprivate.
The "not public API" motivation is directly in view for private/fileprivate.  
Promoting this API to a module would make it API public to our customers.

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

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

[Matt Whiteside via swift-evolution]

> On Mar 23, 2017, at 00:10, Drew Crawford via swift-evolution 
>  wrote:
> 
>> This fails to convince me. 

I had similar thoughts.
> I understand that, but not why.
> 
> I can't go into detail in public, but I can say that we did a postmortem on a 
> large lost sale and the customer specifically cited the number of frameworks 
> in our product as an integration barrier for them.  Most iOS SDKs are 
> distributed as a single framework and so with that backdrop the friction 
> makes more sense.
> 
I find this to be a somewhat convoluted motivation for the feature.  This is a 
shortcoming of tooling/workflow that shows itself in the presence of large 
multi-framework Xcode projects.  In other words, this use case seems fairly 
distant from what was intended for private vs fileprivate.

I also found the earlier example you gave, of using private vs fileprivate to 
create warnings on invalid access of thread state, to be stretching the access 
control beyond what was intended.  This sounds like a job for compiler static 
analysis rather than access control.

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

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

[Vladimir.S via swift-evolution]

On 24.03.2017 17:27, Ross O'Brien wrote:

We should be clear about this, because it seems to me that this is the
source of the 'cognitive load' problem:

Following Alternative 3,
private properties in scopes, would become "scoped".
fileprivate properties in or out of scopes would become "private".
private types, such as protocols, classes, etc., would *stay* "private".
The keyword would consistently mean private to the file, instead of
changing its meaning at different scopes.



You mean private types at top level of file? Or inside other type?
I.e.

private class MyClass{
private class MyChild { 
}
}

should become

private class MyClass{
scoped class MyChild {  
}
}

right?

Actually, it is a good question, if 'scoped' should be allowed at top level 
of file? I believe this is a very important question we need to answer to 
remove the one more big confusion point about Swift's access levels.
'scoped' at top level of file becomes to play a role of another kind of 
access level - file-based. We should "protect" meaning of 'scoped' - it 
should mean only what it is created and used for.


So, IMO Alternative 3 should be extended with statement like: "New 
scope-based access modifier can't be used at top level of file"


Otherwise exactly this possible confusion gives a lot of marks to the 
"remove scoped access level" camp.







On Fri, Mar 24, 2017 at 1:49 PM, Ricardo Parada via swift-evolution
> wrote:

After reading the discussions it seems to me that renaming private ->
scoped and fileprivate -> private might keep both sides happy.



> On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution
> wrote:
>
>> On 24.03.2017 11 :47, Jonathan Hull via
swift-evolution wrote:
>> Nevin had a fantastic proposal for submodules which changed private
to mean
>> “private to the submodule”, where each file was implicitly a submodule
>> unless you declared otherwise.  Simple and elegant.
>
> Currently I don't see how submodules can eliminate the needs of
'scoped'(current 'private') access level. Even in submodule (even if
submodule will be a "namespace" line feature like "submodule Name{..}"
and we can have number of such declarations in the same file) -
'scoped' access is valuable even for single type declaration. Probably
I don't understand something.
>
> But as for fileprivate - it is really logically to have it named
'private' and it can naturally be used in submodules as "private to
submodule" just like "private to file" currently.
>
> So I do think the right move currently is to rename
fileprivate->private, private->scoped and then, when(if!) we have
submodules - we can change something.
> Rename will remove the huge confusion users(especially novice) have
with 'fileprivate' vs 'private'; experience shows that *actually*
programmers use 'fileprivate' a lot and this is some kind of Swift/iOs
programming style, and fileprivate is awkward keyword, and many(all?
;-)  just want 'private' means "in this file".
> Also novice programmer can know just about 'public', 'internal' and
'private' - these three logically united access modifiers,all are
file-scoped, but more experienced programmer has no problems teach what
'scoped' means and why one want to use it.
>
>>
>>
>>> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution
>>> 
>>
wrote:
>>>
>>>
>>>
>>>
>>> Sent from my iPhone
>>> On Mar 23, 2017, at 6:41 PM, David Hart 
>>> >> wrote:
>>>
 I have difficulties imagining a submodule proposal that could allow us
 to eliminate fileprivate. Care to give an example?
>>>
>>> The obvious example would be Rust.  Rust has exactly two visibilities,
>>> and merely one keyword.  By default, members are "private" which is
>>> visible inside the module (so, like Swift's internal). The "public"
>>> keyword is similar to Swift.
>>>
>>> The reason this works is that unlike in Swift where a module is
something
>>> like a library or framework (Rust calls those "crates"), in Rust
modules
>>> in are (explicitly) lexically scoped; a "mod myscope {}" module can be
>>> created for the portion of the file for which the member should be
>>> visible and it won't be visible outside that scope. Likewise,
>>> "fileprivate" can be achieved by enclosing the file in a "mod
MyFile {}".
>>> And like all lexical scopes, they can be recursively nested to

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

[Ross O'Brien via swift-evolution]

We should be clear about this, because it seems to me that this is the
source of the 'cognitive load' problem:

Following Alternative 3,
private properties in scopes, would become "scoped".
fileprivate properties in or out of scopes would become "private".
private types, such as protocols, classes, etc., would *stay* "private".
The keyword would consistently mean private to the file, instead of
changing its meaning at different scopes.





On Fri, Mar 24, 2017 at 1:49 PM, Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

> After reading the discussions it seems to me that renaming private ->
> scoped and fileprivate -> private might keep both sides happy.
>
>
>
> > On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >> On 24.03.2017 11:47, Jonathan Hull via swift-evolution wrote:
> >> Nevin had a fantastic proposal for submodules which changed private to
> mean
> >> “private to the submodule”, where each file was implicitly a submodule
> >> unless you declared otherwise.  Simple and elegant.
> >
> > Currently I don't see how submodules can eliminate the needs of
> 'scoped'(current 'private') access level. Even in submodule (even if
> submodule will be a "namespace" line feature like "submodule Name{..}" and
> we can have number of such declarations in the same file) - 'scoped' access
> is valuable even for single type declaration. Probably I don't understand
> something.
> >
> > But as for fileprivate - it is really logically to have it named
> 'private' and it can naturally be used in submodules as "private to
> submodule" just like "private to file" currently.
> >
> > So I do think the right move currently is to rename
> fileprivate->private, private->scoped and then, when(if!) we have
> submodules - we can change something.
> > Rename will remove the huge confusion users(especially novice) have with
> 'fileprivate' vs 'private'; experience shows that *actually* programmers
> use 'fileprivate' a lot and this is some kind of Swift/iOs programming
> style, and fileprivate is awkward keyword, and many(all? ;-)  just want
> 'private' means "in this file".
> > Also novice programmer can know just about 'public', 'internal' and
> 'private' - these three logically united access modifiers,all are
> file-scoped, but more experienced programmer has no problems teach what
> 'scoped' means and why one want to use it.
> >
> >>
> >>
> >>> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution
> >>> > wrote:
> >>>
> >>>
> >>>
> >>>
> >>> Sent from my iPhone
> >>> On Mar 23, 2017, at 6:41 PM, David Hart  >>> > wrote:
> >>>
>  I have difficulties imagining a submodule proposal that could allow us
>  to eliminate fileprivate. Care to give an example?
> >>>
> >>> The obvious example would be Rust.  Rust has exactly two visibilities,
> >>> and merely one keyword.  By default, members are "private" which is
> >>> visible inside the module (so, like Swift's internal). The "public"
> >>> keyword is similar to Swift.
> >>>
> >>> The reason this works is that unlike in Swift where a module is
> something
> >>> like a library or framework (Rust calls those "crates"), in Rust
> modules
> >>> in are (explicitly) lexically scoped; a "mod myscope {}" module can be
> >>> created for the portion of the file for which the member should be
> >>> visible and it won't be visible outside that scope. Likewise,
> >>> "fileprivate" can be achieved by enclosing the file in a "mod MyFile
> {}".
> >>> And like all lexical scopes, they can be recursively nested to
> arbitrary
> >>> depth to achieve any number of visibility behaviors (e.g., declare a
> >>> module for the first half of two files) that would require complex new
> >>> keywords to achieve in Swift. Finally there are some shortcut features
> >>> like the ability to infer a module structure from the file system.
> >>>
> >>>
> >>>
> >>> In Swift, modules are presently tied to libraries/frameworks in a 1:1
> >>> way. Because of this we lack the flexibility of recursively nestable
> >>> modules of other languages and this is the underlying problem that
> >>> motivates both scoped/private and fileprivate.  If we fixed that, we
> >>> would actually not need either keyword.
> >>>
> >>> http://rustbyexample.com/mod/visibility.html
> >>> https://doc.rust-lang.org/book/crates-and-modules.html
> >>> ___
> >>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Ricardo Parada via swift-evolution]

After reading the discussions it seems to me that renaming private -> scoped 
and fileprivate -> private might keep both sides happy. 



> On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
>> On 24.03.2017 11:47, Jonathan Hull via swift-evolution wrote:
>> Nevin had a fantastic proposal for submodules which changed private to mean
>> “private to the submodule”, where each file was implicitly a submodule
>> unless you declared otherwise.  Simple and elegant.
> 
> Currently I don't see how submodules can eliminate the needs of 
> 'scoped'(current 'private') access level. Even in submodule (even if 
> submodule will be a "namespace" line feature like "submodule Name{..}" and we 
> can have number of such declarations in the same file) - 'scoped' access is 
> valuable even for single type declaration. Probably I don't understand 
> something.
> 
> But as for fileprivate - it is really logically to have it named 'private' 
> and it can naturally be used in submodules as "private to submodule" just 
> like "private to file" currently.
> 
> So I do think the right move currently is to rename fileprivate->private, 
> private->scoped and then, when(if!) we have submodules - we can change 
> something.
> Rename will remove the huge confusion users(especially novice) have with 
> 'fileprivate' vs 'private'; experience shows that *actually* programmers use 
> 'fileprivate' a lot and this is some kind of Swift/iOs programming style, and 
> fileprivate is awkward keyword, and many(all? ;-)  just want 'private' means 
> "in this file".
> Also novice programmer can know just about 'public', 'internal' and 'private' 
> - these three logically united access modifiers,all are file-scoped, but more 
> experienced programmer has no problems teach what 'scoped' means and why one 
> want to use it.
> 
>> 
>> 
>>> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution
>>> > wrote:
>>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> On Mar 23, 2017, at 6:41 PM, David Hart >> > wrote:
>>> 
 I have difficulties imagining a submodule proposal that could allow us
 to eliminate fileprivate. Care to give an example?
>>> 
>>> The obvious example would be Rust.  Rust has exactly two visibilities,
>>> and merely one keyword.  By default, members are "private" which is
>>> visible inside the module (so, like Swift's internal). The "public"
>>> keyword is similar to Swift.
>>> 
>>> The reason this works is that unlike in Swift where a module is something
>>> like a library or framework (Rust calls those "crates"), in Rust modules
>>> in are (explicitly) lexically scoped; a "mod myscope {}" module can be
>>> created for the portion of the file for which the member should be
>>> visible and it won't be visible outside that scope. Likewise,
>>> "fileprivate" can be achieved by enclosing the file in a "mod MyFile {}".
>>> And like all lexical scopes, they can be recursively nested to arbitrary
>>> depth to achieve any number of visibility behaviors (e.g., declare a
>>> module for the first half of two files) that would require complex new
>>> keywords to achieve in Swift. Finally there are some shortcut features
>>> like the ability to infer a module structure from the file system.
>>> 
>>> 
>>> 
>>> In Swift, modules are presently tied to libraries/frameworks in a 1:1
>>> way. Because of this we lack the flexibility of recursively nestable
>>> modules of other languages and this is the underlying problem that
>>> motivates both scoped/private and fileprivate.  If we fixed that, we
>>> would actually not need either keyword.
>>> 
>>> http://rustbyexample.com/mod/visibility.html
>>> https://doc.rust-lang.org/book/crates-and-modules.html
>>> ___
>>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Vladimir.S via swift-evolution]

On 24.03.2017 11:47, Jonathan Hull via swift-evolution wrote:

Nevin had a fantastic proposal for submodules which changed private to mean
“private to the submodule”, where each file was implicitly a submodule
unless you declared otherwise.  Simple and elegant.


Currently I don't see how submodules can eliminate the needs of 
'scoped'(current 'private') access level. Even in submodule (even if 
submodule will be a "namespace" line feature like "submodule Name{..}" and 
we can have number of such declarations in the same file) - 'scoped' access 
is valuable even for single type declaration. Probably I don't understand 
something.


But as for fileprivate - it is really logically to have it named 'private' 
and it can naturally be used in submodules as "private to submodule" just 
like "private to file" currently.


So I do think the right move currently is to rename fileprivate->private, 
private->scoped and then, when(if!) we have submodules - we can change 
something.
Rename will remove the huge confusion users(especially novice) have with 
'fileprivate' vs 'private'; experience shows that *actually* programmers 
use 'fileprivate' a lot and this is some kind of Swift/iOs programming 
style, and fileprivate is awkward keyword, and many(all? ;-)  just want 
'private' means "in this file".
Also novice programmer can know just about 'public', 'internal' and 
'private' - these three logically united access modifiers,all are 
file-scoped, but more experienced programmer has no problems teach what 
'scoped' means and why one want to use it.






On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution
> wrote:




Sent from my iPhone
On Mar 23, 2017, at 6:41 PM, David Hart > wrote:


I have difficulties imagining a submodule proposal that could allow us
to eliminate fileprivate. Care to give an example?


The obvious example would be Rust.  Rust has exactly two visibilities,
and merely one keyword.  By default, members are "private" which is
visible inside the module (so, like Swift's internal). The "public"
keyword is similar to Swift.

The reason this works is that unlike in Swift where a module is something
like a library or framework (Rust calls those "crates"), in Rust modules
in are (explicitly) lexically scoped; a "mod myscope {}" module can be
created for the portion of the file for which the member should be
visible and it won't be visible outside that scope. Likewise,
"fileprivate" can be achieved by enclosing the file in a "mod MyFile {}".
And like all lexical scopes, they can be recursively nested to arbitrary
depth to achieve any number of visibility behaviors (e.g., declare a
module for the first half of two files) that would require complex new
keywords to achieve in Swift. Finally there are some shortcut features
like the ability to infer a module structure from the file system.



In Swift, modules are presently tied to libraries/frameworks in a 1:1
way. Because of this we lack the flexibility of recursively nestable
modules of other languages and this is the underlying problem that
motivates both scoped/private and fileprivate.  If we fixed that, we
would actually not need either keyword.

http://rustbyexample.com/mod/visibility.html
https://doc.rust-lang.org/book/crates-and-modules.html
___
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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Karim Nassar via swift-evolution]

> What is your evaluation of the proposal?
A very reluctant -1. “Reluctant" because I suspect that we won’t get another 
chance to revisit this, and I *do* think it’s broken.

I’m in the camp that believes the result we got out of SE-25 was not helpful to 
the evolution of Swift, and I would like to see us reverse the decision. I 
strongly believe that -25 was a mistake, and took access controls in the wrong 
direction. 

However, I’m not blind to the fact that while *I* don’t have much use for 
`private` in its Swift3 meaning, there are others who are making good use of 
it. I have no desire to make the language less expressive for them. 

I *would* be strongly supportive of a proposal to rename `private` -> `scoped` 
and `fileprivate` -> `private`. This would solve many of the confusion & 
complications resulting from -25 without making the language less expressive 
for those currently depending on `private`. Alas, that is not the proposal 
being evaluated.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
While I believe that there is a significant problem that needs to be addressed 
with regards to access controls in Swift, I don’t believe this proposal 
sufficiently addresses it.

Adding more expressiveness at the smallest end of the visibility spectrum 
(SE-25) has simply aggravated the “Very Large File” syndrome that continues to 
plague my Swift projects. IMHO, what we really need is more expressiveness in 
the *middle* of the spectrum (i.e.: between the Module `internal` and the file 
`file/private` expression so that we can hide details of tightly coupled 
implementations within a larger module without glomming all those 
implementations into a single file.

This proposal doesn’t actually solve the problem, it simply pretties-up the 
spelling of `fileprivate` and removes a feature (scoped private) that some 
members of the community seem to depend on. 

> Does this proposal fit well with the feel and direction of Swift?
Yes. I believe that the spelling `fileprivate` is clunky and inelegant and 
creates cognitive dissonance by coexisting with `private`, and that private has 
a non-intuitive meaning to anyone not being taught Swift as their first PL.

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

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Have followed the discussion since SE-25 was passed. Have been using Swift 
since its announcement, studied the proposal and considered its implications 
for some time.

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

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 23, 2017, at 9:48 PM, Charles Srstka  wrote:
> 
>> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> On Mar 23, 2017, at 8:27 PM, Drew Crawford  wrote:
>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
>>> 
 I have difficulties imagining a submodule proposal that could allow us to 
 eliminate fileprivate. Care to give an example?
>>> 
>>> The obvious example would be Rust.  Rust has exactly two visibilities, and 
>>> merely one keyword.  By default, members are "private" which is visible 
>>> inside the module (so, like Swift's internal). The "public" keyword is 
>>> similar to Swift. 
>>> 
>>> The reason this works is that unlike in Swift where a module is something 
>>> like a library or framework (Rust calls those "crates"), in Rust modules in 
>>> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
>>> for the portion of the file for which the member should be visible and it 
>>> won't be visible outside that scope. Likewise, "fileprivate" can be 
>>> achieved by enclosing the file in a "mod MyFile {}". And like all lexical 
>>> scopes, they can be recursively nested to arbitrary depth to achieve any 
>>> number of visibility behaviors (e.g., declare a module for the first half 
>>> of two files) that would require complex new keywords to achieve in Swift. 
>>> Finally there are some shortcut features like the ability to infer a module 
>>> structure from the file system. 
>> 
>> This is a good example of what I meant.  There is an extremely broad range 
>> of possible designs for submodules.  Some of them, such as this example, 
>> would make it relatively easy to get by without fileprivate.  There are also 
>> many other possible designs that would not.  
>> 
>> We do not have any idea where Swift will end up yet.  It's not reasonable to 
>> make any assumptions about what use cases the eventual design might or might 
>> not address.
> 
> Then why not leave private and fileprivate alone until we do?

That is what I have suggested, with an alternative of renaming if we feel 
compelled to make a change now.

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

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

[Marco Masser via swift-evolution]

I also add my voice on the -1 side and fully agree with Drew’s reasoning.
`private` and `fileprivate` have a very distinct use in the code I write and in 
my opinion both carry their weight.

I’m not opposed to renaming or changing access modifiers, but I don’t see the 
need for it now. I agree with what others wrote that this topic should be 
revisited in the context of submodules, whenever that will be. Taking away the 
functionality of the current `private` by a confusingly written proposal that 
does not address the reasons for its introduction (or support the claims in the 
proposal itself with facts, for that matter) seems like a bad idea.

Cheers,

Marco


> On 2017-03-21, at 02:26, Drew Crawford via swift-evolution 
>  wrote:
> 
> I disagree quite strongly with the proposal.
> 
> First, the document draws conclusions without apparent supporting evidence, 
> e.g.
> 
> > Since the release of Swift 3, the access level change of SE–0025 was met 
> > with dissatisfaction by a substantial proportion of the general Swift 
> > community. Those changes can be viewed as actively harmful, the new 
> > requirement for syntax/API changes.
> What is “dissatisfaction by a substantial proportion of the general Swift 
> community”? How was this measured/determined?
> What was done to control for the population happy with SE-0025 who would e.g. 
> not be likely to take up pitchforks?
> Who argues these changes are “actively harmful” and where were they during 
> SE-0025?
> > subtly encourages overuse of scoped access control and discourages the more 
> > reasonable default
> Who claims that scoped access is “overused” and what is their argument for 
> doing so?
> Why is “fileprivate” the “more reasonable default”? In fact neither 
> fileprivate *nor* private are default (reasonable or not!). Internal is the 
> default. Nor does this proposal suggest we change that. So this seems a very 
> strange statement.
> > But is that distinction between private and fileprivate actively used by 
> > the larger community of Swift developers?
> Yes. To cite some evidence, here are codebases I actively maintain:
> 
> | codebase   | private # | 
> fileprivate # | ratio |
> 
> ||---|---|---|
> 
> | "M" (proprietary)  | 486   | 249
>| 2x|
> 
> | "N"(proprietary)   | 179   | 59 
>| 3x|
> 
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH 
>  | 15| 1   
>   | 15x   |
> 
> | atbuild https://github.com/AnarchyTools/atbuild 
> | 54| 5 
> | 11x   |
> 
> So from my chair, not only is the distinction useful, but scoped access 
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
> 
> > And if it were used pervasively, would it be worth the cognitive load and 
> > complexity of keeping two very similar access levels in the language? This 
> > proposal argues that answer to both questions is no
> 
> This proposal does not make any later argument about “cognitive load” or 
> “complexity” I can identify.  Did the proposal get truncated?
> 
> What is stated (without evidence) is that "it is extremely common to use 
> several extensions within a file” and that use of “private” is annoying in 
> that case.  I now extend the above table
> 
> | codebase   | private # | 
> fileprivate # | ratio | # of extensions (>=3 extensions in file) |
> 
> ||---|---|---|--|
> 
> | "M" (proprietary)  | 486   | 249
>| 2x| 48   |
> 
> | "N"(proprietary)   | 179   | 59 
>| 3x| 84   |
> 
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH 
>  | 15| 1   
>   | 15x   | 3|
> 
> | atbuild https://github.com/AnarchyTools/atbuild 
> | 54| 5 
> | 11x   | 6|
> 
> in order to demonstrate in my corner of Swift this is not “extremely common”, 
> and is actually less popular than language features the proposal alleges 
> aren’t used.
> 
> My point here is that **different people in different corners of the 
> community program Swift differently and use different styles**.  I can 
> definitely empathize with folks like the author who use extensions to group 
> functions and are annoyed that their 

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

[Jonathan Hull via swift-evolution]

Nevin had a fantastic proposal for submodules which changed private to mean 
“private to the submodule”, where each file was implicitly a submodule unless 
you declared otherwise.  Simple and elegant.


> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
> 
> Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart  > wrote:
> 
>> I have difficulties imagining a submodule proposal that could allow us to 
>> eliminate fileprivate. Care to give an example?
> 
> The obvious example would be Rust.  Rust has exactly two visibilities, and 
> merely one keyword.  By default, members are "private" which is visible 
> inside the module (so, like Swift's internal). The "public" keyword is 
> similar to Swift. 
> 
> The reason this works is that unlike in Swift where a module is something 
> like a library or framework (Rust calls those "crates"), in Rust modules in 
> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
> for the portion of the file for which the member should be visible and it 
> won't be visible outside that scope. Likewise, "fileprivate" can be achieved 
> by enclosing the file in a "mod MyFile {}". And like all lexical scopes, they 
> can be recursively nested to arbitrary depth to achieve any number of 
> visibility behaviors (e.g., declare a module for the first half of two files) 
> that would require complex new keywords to achieve in Swift. Finally there 
> are some shortcut features like the ability to infer a module structure from 
> the file system. 
> 
> 
> 
> In Swift, modules are presently tied to libraries/frameworks in a 1:1 way. 
> Because of this we lack the flexibility of recursively nestable modules of 
> other languages and this is the underlying problem that motivates both 
> scoped/private and fileprivate.  If we fixed that, we would actually not need 
> either keyword. 
> 
> http://rustbyexample.com/mod/visibility.html 
> 
> https://doc.rust-lang.org/book/crates-and-modules.html 
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 24 Mar 2017, at 05:36, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I agree with everything you wrote here. And it is for that reason that I 
> would expect that any future proposal for submodules should be judged in no 
> small part on its _not_ changing circumstances surrounding access modifiers, 
> such that no further proposals to revisit this topic will come up. It's one 
> thing to have one-off discussions to back out a change that in hindsight 
> seems unwise; it's quite another to have the community return to the same 
> topic over and over like this. No more. Let's do this never again.

It was not the people using and liking private's scope based visibility which 
brought this proposal forward and should be punished because of it.
I can understand what you are saying and where you are coming from, but it is 
not an argument strong enough to justify removing this access level for IMHO, 
quite the opposite really. 
Also, I do not think the core team would not want to revisit this/accept to 
revisit this once a good submodule design like the one Rust has were to be 
implemented into Swift.

>> On Fri, Mar 24, 2017 at 00:04 Drew Crawford  wrote:
 Or, since many designs for submodules are possible... confident that there 
 will be a good design for submodules
>>> 
>>> We lack any real information on what Swift designs are possible.  We can 
>>> look to other languages for inspiration but they cannot be transplanted 
>>> wholesale into Swift from a technical, practical, or cultural perspective.  
>>> Rust isn't Swift.
>>> 
>> 
>>> Given, as some have said above, many different submodule designs are 
>>> possible whatever the number of access levels, I would expect that we would 
>>> not revisit this topic again for the foreseeable future, whatever the 
>>> decision is.
>> 
>> I think it would be appropriate to revisit this if we have new information.  
>> You have previously argued that there is substantial new information which 
>> you present as a rationale to revisit it now.  I don't accept the premise, 
>> but I do accept the argument: if the circumstances change it's appropriate 
>> to take another look.
>> 
>> 
>>> On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution 
>>> (swift-evolution@swift.org) wrote:
>>> Or, since many designs for submodules are possible, we can proceed to make 
>>> the best decision *now* with respect to access levels, confident that there 
>>> will be a good design for submodules whether or not there exist both scoped 
>>> and file-based private access. That is to say, any future submodule 
>>> proposal would be judged on how well it accommodates desired use cases if 
>>> one type of private is removed, and any future design for submodules would 
>>> be judged on how well it fits with the current set of access levels without 
>>> duplicating functionality with a different syntax if both types of private 
>>> are retained.
>>> 
>>> One very important thing about the evolution process (IMO) is that 
>>> decisions made aren't revisited without compelling changes in 
>>> circumstances. It is highly unusual that fileprivate vs. private is now 
>>> going through this process for a _third_ time. I submit that it is 
>>> untenable that every version of Swift should consider a change to the 
>>> access modifiers. Given, as some have said above, many different submodule 
>>> designs are possible whatever the number of access levels, I would expect 
>>> that we would not revisit this topic again for the foreseeable future, 
>>> whatever the decision is. That is, the question being asked here is, is it 
>>> better for Swift to have both fileprivate and private for all time, or one 
>>> file-scoped private for all time?
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

I agree with everything you wrote here. And it is for that reason that I
would expect that any future proposal for submodules should be judged in no
small part on its _not_ changing circumstances surrounding access
modifiers, such that no further proposals to revisit this topic will come
up. It's one thing to have one-off discussions to back out a change that in
hindsight seems unwise; it's quite another to have the community return to
the same topic over and over like this. No more. Let's do this never again.
On Fri, Mar 24, 2017 at 00:04 Drew Crawford  wrote:

> Or, since many designs for submodules are possible... confident that
> there will be a good design for submodules
>
> We lack any real information on what Swift designs are possible.  We can
> look to other languages for inspiration but they cannot be transplanted
> wholesale into Swift from a technical, practical, or cultural perspective.
> Rust isn't Swift.
>
> Given, as some have said above, many different submodule designs are
> possible whatever the number of access levels, I would expect that we would
> not revisit this topic again for the foreseeable future, whatever the
> decision is.
>
> I think it would be appropriate to revisit this if we have new
> information.  You have previously argued that there is substantial new
> information which you present as a rationale to revisit it now.  I don't
> accept the premise, but I do accept the argument: if the circumstances
> change it's appropriate to take another look.
>
> On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> Or, since many designs for submodules are possible, we can proceed to make
> the best decision *now* with respect to access levels, confident that there
> will be a good design for submodules whether or not there exist both scoped
> and file-based private access. That is to say, any future submodule
> proposal would be judged on how well it accommodates desired use cases if
> one type of private is removed, and any future design for submodules would
> be judged on how well it fits with the current set of access levels without
> duplicating functionality with a different syntax if both types of private
> are retained.
>
> One very important thing about the evolution process (IMO) is that
> decisions made aren't revisited without compelling changes in
> circumstances. It is highly unusual that fileprivate vs. private is now
> going through this process for a _third_ time. I submit that it is
> untenable that every version of Swift should consider a change to the
> access modifiers. Given, as some have said above, many different submodule
> designs are possible whatever the number of access levels, I would expect
> that we would not revisit this topic again for the foreseeable future,
> whatever the decision is. That is, the question being asked here is, is it
> better for Swift to have both fileprivate and private for all time, or one
> file-scoped private for all time?
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Drew Crawford via swift-evolution]

Or, since many designs for submodules are possible... confident that there will 
be a good design for submodules
We lack any real information on what Swift designs are possible.  We can look 
to other languages for inspiration but they cannot be transplanted wholesale 
into Swift from a technical, practical, or cultural perspective.  Rust isn't 
Swift.

Given, as some have said above, many different submodule designs are possible 
whatever the number of access levels, I would expect that we would not revisit 
this topic again for the foreseeable future, whatever the decision is.
I think it would be appropriate to revisit this if we have new information.  
You have previously argued that there is substantial new information which you 
present as a rationale to revisit it now.  I don't accept the premise, but I do 
accept the argument: if the circumstances change it's appropriate to take 
another look.


On March 23, 2017 at 11:12:32 PM, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) wrote:
Or, since many designs for submodules are possible, we can proceed to make the 
best decision *now* with respect to access levels, confident that there will be 
a good design for submodules whether or not there exist both scoped and 
file-based private access. That is to say, any future submodule proposal would 
be judged on how well it accommodates desired use cases if one type of private 
is removed, and any future design for submodules would be judged on how well it 
fits with the current set of access levels without duplicating functionality 
with a different syntax if both types of private are retained.

One very important thing about the evolution process (IMO) is that decisions 
made aren't revisited without compelling changes in circumstances. It is highly 
unusual that fileprivate vs. private is now going through this process for a 
_third_ time. I submit that it is untenable that every version of Swift should 
consider a change to the access modifiers. Given, as some have said above, many 
different submodule designs are possible whatever the number of access levels, 
I would expect that we would not revisit this topic again for the foreseeable 
future, whatever the decision is. That is, the question being asked here is, is 
it better for Swift to have both fileprivate and private for all time, or one 
file-scoped private for all time?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwynne Raskind via swift-evolution]

Big -1 from me. While I don't like fileprivate at all, removing private as it 
presently exists is not the answer. For details on my thoughts, please refer to 
Drew Crawford's excellent responses to this proposal; he states it far better 
than I ever could :)

-- Gwynne Raskind

> On Mar 20, 2017, at 18:54, Douglas Gregor  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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

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

[Xiaodi Wu via swift-evolution]

Or, since many designs for submodules are possible, we can proceed to make
the best decision *now* with respect to access levels, confident that there
will be a good design for submodules whether or not there exist both scoped
and file-based private access. That is to say, any future submodule
proposal would be judged on how well it accommodates desired use cases if
one type of private is removed, and any future design for submodules would
be judged on how well it fits with the current set of access levels without
duplicating functionality with a different syntax if both types of private
are retained.

One very important thing about the evolution process (IMO) is that
decisions made aren't revisited without compelling changes in
circumstances. It is highly unusual that fileprivate vs. private is now
going through this process for a _third_ time. I submit that it is
untenable that every version of Swift should consider a change to the
access modifiers. Given, as some have said above, many different submodule
designs are possible whatever the number of access levels, I would expect
that we would not revisit this topic again for the foreseeable future,
whatever the decision is. That is, the question being asked here is, is it
better for Swift to have both fileprivate and private for all time, or one
file-scoped private for all time?
On Thu, Mar 23, 2017 at 21:48 Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Mar 23, 2017, at 8:27 PM, Drew Crawford 
> wrote:
>
>
>
>
> Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
>
> I have difficulties imagining a submodule proposal that could allow us to
> eliminate fileprivate. Care to give an example?
>
>
> The obvious example would be Rust.  Rust has exactly two visibilities, and
> merely one keyword.  By default, members are "private" which is visible
> inside the module (so, like Swift's internal). The "public" keyword is
> similar to Swift.
>
> The reason this works is that unlike in Swift where a module is something
> like a library or framework (Rust calls those "crates"), in Rust modules in
> are (explicitly) lexically scoped; a "mod myscope {}" module can be created
> for the portion of the file for which the member should be visible and it
> won't be visible outside that scope. Likewise, "fileprivate" can be
> achieved by enclosing the file in a "mod MyFile {}". And like all lexical
> scopes, they can be recursively nested to arbitrary depth to achieve any
> number of visibility behaviors (e.g., declare a module for the first half
> of two files) that would require complex new keywords to achieve in Swift.
>  Finally there are some shortcut features like the ability to infer a
> module structure from the file system.
>
>
> This is a good example of what I meant.  There is an extremely broad range
> of possible designs for submodules.  Some of them, such as this example,
> would make it relatively easy to get by without fileprivate.  There are
> also many other possible designs that would not.
>
> We do not have any idea where Swift will end up yet.  It's not reasonable
> to make any assumptions about what use cases the eventual design might or
> might not address.
>
>
> Then why not leave private and fileprivate alone until we do?
>
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Charles Srstka via swift-evolution]

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> On Mar 23, 2017, at 8:27 PM, Drew Crawford  > wrote:
> 
>> 
>> 
>> 
>> Sent from my iPhone
>> On Mar 23, 2017, at 6:41 PM, David Hart > > wrote:
>> 
>>> I have difficulties imagining a submodule proposal that could allow us to 
>>> eliminate fileprivate. Care to give an example?
>> 
>> The obvious example would be Rust.  Rust has exactly two visibilities, and 
>> merely one keyword.  By default, members are "private" which is visible 
>> inside the module (so, like Swift's internal). The "public" keyword is 
>> similar to Swift. 
>> 
>> The reason this works is that unlike in Swift where a module is something 
>> like a library or framework (Rust calls those "crates"), in Rust modules in 
>> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
>> for the portion of the file for which the member should be visible and it 
>> won't be visible outside that scope. Likewise, "fileprivate" can be achieved 
>> by enclosing the file in a "mod MyFile {}". And like all lexical scopes, 
>> they can be recursively nested to arbitrary depth to achieve any number of 
>> visibility behaviors (e.g., declare a module for the first half of two 
>> files) that would require complex new keywords to achieve in Swift. Finally 
>> there are some shortcut features like the ability to infer a module 
>> structure from the file system. 
> 
> This is a good example of what I meant.  There is an extremely broad range of 
> possible designs for submodules.  Some of them, such as this example, would 
> make it relatively easy to get by without fileprivate.  There are also many 
> other possible designs that would not.  
> 
> We do not have any idea where Swift will end up yet.  It's not reasonable to 
> make any assumptions about what use cases the eventual design might or might 
> not address.

Then why not leave private and fileprivate alone until we do?

Charles

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

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 23, 2017, at 8:27 PM, Drew Crawford  wrote:
> 
> 
> 
> 
> Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
> 
>> I have difficulties imagining a submodule proposal that could allow us to 
>> eliminate fileprivate. Care to give an example?
> 
> The obvious example would be Rust.  Rust has exactly two visibilities, and 
> merely one keyword.  By default, members are "private" which is visible 
> inside the module (so, like Swift's internal). The "public" keyword is 
> similar to Swift. 
> 
> The reason this works is that unlike in Swift where a module is something 
> like a library or framework (Rust calls those "crates"), in Rust modules in 
> are (explicitly) lexically scoped; a "mod myscope {}" module can be created 
> for the portion of the file for which the member should be visible and it 
> won't be visible outside that scope. Likewise, "fileprivate" can be achieved 
> by enclosing the file in a "mod MyFile {}". And like all lexical scopes, they 
> can be recursively nested to arbitrary depth to achieve any number of 
> visibility behaviors (e.g., declare a module for the first half of two files) 
> that would require complex new keywords to achieve in Swift. Finally there 
> are some shortcut features like the ability to infer a module structure from 
> the file system. 

This is a good example of what I meant.  There is an extremely broad range of 
possible designs for submodules.  Some of them, such as this example, would 
make it relatively easy to get by without fileprivate.  There are also many 
other possible designs that would not.  

We do not have any idea where Swift will end up yet.  It's not reasonable to 
make any assumptions about what use cases the eventual design might or might 
not address.

> 
> 
> 
> In Swift, modules are presently tied to libraries/frameworks in a 1:1 way. 
> Because of this we lack the flexibility of recursively nestable modules of 
> other languages and this is the underlying problem that motivates both 
> scoped/private and fileprivate.  If we fixed that, we would actually not need 
> either keyword. 
> 
> http://rustbyexample.com/mod/visibility.html
> https://doc.rust-lang.org/book/crates-and-modules.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Drew Crawford via swift-evolution]

Sent from my iPhone
> On Mar 23, 2017, at 6:41 PM, David Hart  wrote:
> 
> I have difficulties imagining a submodule proposal that could allow us to 
> eliminate fileprivate. Care to give an example?

The obvious example would be Rust.  Rust has exactly two visibilities, and 
merely one keyword.  By default, members are "private" which is visible inside 
the module (so, like Swift's internal). The "public" keyword is similar to 
Swift. 

The reason this works is that unlike in Swift where a module is something like 
a library or framework (Rust calls those "crates"), in Rust modules in are 
(explicitly) lexically scoped; a "mod myscope {}" module can be created for the 
portion of the file for which the member should be visible and it won't be 
visible outside that scope. Likewise, "fileprivate" can be achieved by 
enclosing the file in a "mod MyFile {}". And like all lexical scopes, they can 
be recursively nested to arbitrary depth to achieve any number of visibility 
behaviors (e.g., declare a module for the first half of two files) that would 
require complex new keywords to achieve in Swift. Finally there are some 
shortcut features like the ability to infer a module structure from the file 
system. 



In Swift, modules are presently tied to libraries/frameworks in a 1:1 way. 
Because of this we lack the flexibility of recursively nestable modules of 
other languages and this is the underlying problem that motivates both 
scoped/private and fileprivate.  If we fixed that, we would actually not need 
either keyword. 

http://rustbyexample.com/mod/visibility.html
https://doc.rust-lang.org/book/crates-and-modules.html___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Drew Crawford via swift-evolution]

> But with static linking, your user wouldn’t have to drag 4 .a libraries but 
> only one, which contains all libraries statically linked together.

Static linking is unrelated to merging modules. We can statically link 
libraries on Linux right now, this does not reduce the files on disk or reduce 
the number of statements required to import them etc. 

> Those stats are misleading: an enormous majority of the search results 
> concerning “duplicate symbol” concern incorrect build settings, not a wish to 
> use different versions of the same code.

This is inaccurate, the build settings are workarounds to the problem that 
different versions of the same code (or at least sharing the same C name) are 
in use.  

Swift's visibility is not nearly as configurable as C'a from a build setting 
point of view, although we do have some (e.g. Test mode)



Sent from my iPhone

> On Mar 23, 2017, at 6:52 PM, David Hart  wrote:
> 
> 
>>> On 23 Mar 2017, at 21:49, Drew Crawford  wrote:
>>> 
>>> I'm curious to hear what issue your client had with you using many 
>>> frameworks that static linking doesn't solve.
>> 
>> The issue here is the number of frameworks that the user drags and drops 
>> into Xcode.  Most libraries ship as a single framework, see this page for a 
>> typical example of what the installation documentation for this process 
>> generally looks like.
>> 
>> From a user POV, there is no difference between dragging 4 frameworks and 
>> dragging 4 .a libraries.  Actually, the .a case is worse in Swift because in 
>> addition to object code (.a) we have .swiftmodule, .swiftdoc, and 
>> .modulemap.  So that's a lot of files to drag.
> 
> But with static linking, your user wouldn’t have to drag 4 .a libraries but 
> only one, which contains all libraries statically linked together.
> 
>> I have been involved in generating solutions for this problem in other areas 
>> (see the atbin standard for example) but none of them are supported by Xcode.
>> 
>> Finally, static linking has nothing to do with visibility or the problems of 
>> exposing these frameworks as public API.
>> 
>>> I don't see why submodules could not profit from WMO: the module is still 
>>> compiled all together. Submodules are simply a scoping/hiding mechanism.
>> 
>> Then you will be surprised to hear that this is a subject of some debate.  
>> Relevant thread.
>> 
>>> That looks like a very corner case. I haven't yet found myself in the case 
>>> where I needed multiple versions of a code base in a same product (binary, 
>>> framework, application)
>> 
>> 
>> There are 253 pages of search results for "duplicate symbol" on 
>> StackOverflow.  Compare with 48 pages on fileprivate.  It is quite clear 
>> which is the more complicated feature.
> 
> Those stats are misleading: an enormous majority of the search results 
> concerning “duplicate symbol” concern incorrect build settings, not a wish to 
> use different versions of the same code.
> 
>>> It would be very strange to me if they were independent libraries: what 
>>> would different them from modules then?
>> 
>> The organization of object code on the filesystem does not necessarily have 
>> any relationship to "submodules the philosophical construct".
>> 
>>> But at the same time, we can't write and review proposals with no regard 
>>> for future proposals coming down the road or we end up with a clunky 
>>> language.
>> 
>> 
>> I'm not aware of evidence any submodule proposal is actually coming.  For 
>> example here is the only authoritative statement of the feature, "slated" 
>> for Swift 1.0 , a giant warning that we do not even have a design, and the 
>> doc mostly consists of questions for how the feature should work.
> 
> Well the community has definitely shown a LOT of interest in the topic during 
> the last year. I’d be surprised if a proposal wouldn’t be put through review 
> as soon as it’s “in scope”.
> 
>> A scoped access modifier on the other hand is a feature that was designed, 
>> is implemented, and is now widely used. What you are suggesting is we should 
>> throw it away because at any moment a bird could appear in the bush.
> 
> No. I’m suggesting we throw it away because I argue that it brings more 
> confusion and complexity to the language than it solves problems. Again, I’m 
> not saying you and other people don’t use it: we all have our own development 
> experiences. But that hasn’t stoped us from removing features in the past. 
> The submodule argument was just to mention that it would solve some of the 
> same problems you are solving with scoped-private today.
> 
>> But we've waited for that bird for 3 releases.  Rather, if that bird were to 
>> appear, we could then study whether or not it solves all the problems of the 
>> bird in our hand, or whether it does not.  But that hypothetical is quite 
>> far from the present circumstance.
>>> On March 23, 2017 at 2:02:25 PM, David Hart (da...@hartbit.com) wrote:

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

[David Hart via swift-evolution]

> On 23 Mar 2017, at 21:49, Drew Crawford  wrote:
> 
>> I'm curious to hear what issue your client had with you using many 
>> frameworks that static linking doesn't solve.
> 
> The issue here is the number of frameworks that the user drags and drops into 
> Xcode.  Most libraries ship as a single framework, see this page 
>  for a typical example of what the 
> installation documentation for this process generally looks like.
> 
> From a user POV, there is no difference between dragging 4 frameworks and 
> dragging 4 .a libraries.  Actually, the .a case is worse in Swift because in 
> addition to object code (.a) we have .swiftmodule, .swiftdoc, and .modulemap. 
>  So that's a lot of files to drag.

But with static linking, your user wouldn’t have to drag 4 .a libraries but 
only one, which contains all libraries statically linked together.

> I have been involved in generating solutions for this problem in other areas 
> (see the atbin standard  for 
> example) but none of them are supported by Xcode.
> 
> Finally, static linking has nothing to do with visibility or the problems of 
> exposing these frameworks as public API.
> 
>> I don't see why submodules could not profit from WMO: the module is still 
>> compiled all together. Submodules are simply a scoping/hiding mechanism.
> 
> Then you will be surprised to hear that this is a subject of some debate.  
> Relevant thread. 
> 
> 
>> That looks like a very corner case. I haven't yet found myself in the case 
>> where I needed multiple versions of a code base in a same product (binary, 
>> framework, application)
> 
> 
> There are 253 pages  of 
> search results for "duplicate symbol" on StackOverflow.  Compare with 48 
> pages  on fileprivate.  It is 
> quite clear which is the more complicated feature.

Those stats are misleading: an enormous majority of the search results 
concerning “duplicate symbol” concern incorrect build settings, not a wish to 
use different versions of the same code.

>> It would be very strange to me if they were independent libraries: what 
>> would different them from modules then?
> 
> The organization of object code on the filesystem does not necessarily have 
> any relationship to "submodules the philosophical construct".
> 
>> But at the same time, we can't write and review proposals with no regard for 
>> future proposals coming down the road or we end up with a clunky language.
> 
> 
> I'm not aware of evidence any submodule proposal is actually coming.  For 
> example here 
>  is the only 
> authoritative statement of the feature, "slated" for Swift 1.0 , a giant 
> warning that we do not even have a design, and the doc mostly consists of 
> questions for how the feature should work.

Well the community has definitely shown a LOT of interest in the topic during 
the last year. I’d be surprised if a proposal wouldn’t be put through review as 
soon as it’s “in scope”.

> A scoped access modifier on the other hand is a feature that was designed, is 
> implemented, and is now widely used. What you are suggesting is we should 
> throw it away because at any moment a bird could appear in the bush.

No. I’m suggesting we throw it away because I argue that it brings more 
confusion and complexity to the language than it solves problems. Again, I’m 
not saying you and other people don’t use it: we all have our own development 
experiences. But that hasn’t stoped us from removing features in the past. The 
submodule argument was just to mention that it would solve some of the same 
problems you are solving with scoped-private today.

> But we've waited for that bird for 3 releases.  Rather, if that bird were to 
> appear, we could then study whether or not it solves all the problems of the 
> bird in our hand, or whether it does not.  But that hypothetical is quite far 
> from the present circumstance.
> On March 23, 2017 at 2:02:25 PM, David Hart (da...@hartbit.com 
> ) wrote:
> 
>> 
>> 
>> On 23 Mar 2017, at 16:49, Drew Crawford > > wrote:
>> 
>>> 
>>> 
>>> 
>>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com 
>>> ) wrote:
>>> 
 > We will get static linking at some point in the near future.
>>> 
>>> Static linking does not fix this issue. Just change "framework" to ".a".
>>> 
>> I'm curious to hear what issue your client had with you using many 
>> frameworks that static linking doesn't solve.
>> 
 > If we wait until we get submodules, we won't be able to revisit. This is 
 > probably our last chance to "remove" a feature. Submodules can always 

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

[David Hart via swift-evolution]

> On 23 Mar 2017, at 20:18, Matthew Johnson  wrote:
> 
> 
>> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> On 23 Mar 2017, at 16:49, Drew Crawford > > wrote:
>> 
>>> 
>>> 
>>> 
>>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com 
>>> ) wrote:
>>> 
 > We will get static linking at some point in the near future.
>>> 
>>> Static linking does not fix this issue. Just change "framework" to ".a".
>>> 
>> I'm curious to hear what issue your client had with you using many 
>> frameworks that static linking doesn't solve.
>> 
 > If we wait until we get submodules, we won't be able to revisit. This is 
 > probably our last chance to "remove" a feature. Submodules can always 
 > add features down the way.
>>> 
>>> Maybe submodules will solve this issue, maybe not.  But submodules are 
>>> *much* more complex than scoped access:
>>> 
>>> * Performance.  This is hot code we compile with WMO.  Moving it into a 
>>> submodule could reduce visibility for optimization in a way that causes a 
>>> performance regression.  In particular, we know that specialization of T is 
>>> a performance requirement, it isn't clear whether that would be preserved.  
>>> Does WMO provide the same visibility across submodules?  Nobody knows.
>>> 
>> I don't see why submodules could not profit from WMO: the module is still 
>> compiled all together. Submodules are simply a scoping/hiding mechanism.
>>> * Namespacing.  It's possible that one program may ship 3-4 versions of 
>>> this code because each dependency has a slightly different version under 
>>> our current samizdat process.  It is not clear whether submodules would 
>>> avoid the "duplicate symbols" issue from C/ObjC.  Xiaodi seems quite 
>>> concerned about a related "duplicate functions" problem involved with 
>>> private today, doubling down on that is not a good idea.
>>> 
>> That looks like a very corner case. I haven't yet found myself in the case 
>> where I needed multiple versions of a code base in a same product (binary, 
>> framework, application)
>>> * It is not clear whether submodules are from an objectcode point of view 
>>> merged into the parent library or kept as individual libraries
>>> 
>> It would be very strange to me if they were independent libraries: what 
>> would different them from modules then? No other language I've used works 
>> that way.
>>> * It is not clear from a .swiftmodule point of view whether submodules are 
>>> merged into the parent module or distributed as .swiftmodules / .swiftdocs
>>> 
>>> * Not clear how much ABI impact there is from submodules at a time when we 
>>> are supposed to be trying to stabilize it
>>> 
>>> I would love to believe that a proposal on submodules will come through 
>>> having solutions to all these issues and many more, then we will implement 
>>> it and all sing kumbayah.  But we are a long distance from that, and it may 
>>> never happen at all, certainly we cannot evaluate proposals that haven't 
>>> been written.  Meanwhile we have a solution in the hand.
>>> 
>> But at the same time, we can't write and review proposals with no regard for 
>> future proposals coming down the road or we end up with a clunky language.
> 
> Or we can just wait until access control and / or submodules are part of a 
> release theme and address these issues more holistically.

Its worth asking the core team, but I have the impression that a submodule 
proposal (Swift 4+ now) will have much less leeway to remove features. So if we 
don’t remove scoped-based private now, we might not be able to remove it later, 
even if we wish we could.

> As I have said before, the details of the submodule design we eventually end 
> up with could influence what problems people want access control to address 
> (or not address).  It’s possible that we could end up with a design that 
> allows us to eliminate `fileprivate` instead of `private` if we feel we must 
> eliminate one of them.

I have difficulties imagining a submodule proposal that could allow us to 
eliminate fileprivate. Care to give an example?

> Right now we just don’t know enough to say for sure.
> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

On March 23, 2017 at 12:32:38 PM, Brent Royal-Gordon (br...@architechies.com) 
wrote:

To what extent could your need for safety be satisfied by (a) giving the 
property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a 
very small unit test/shell script/Perl script which makes sure references to 
that very unique name only appear between the two "MARK:" comments?
A third-party linter to get a scoped feature is our current candidate for 
reimplementing this feature if it's dropped from Swift.

However, I think it's worth asking to what extent it makes sense to build a 
language that gets fixed with linters.  For example Swift could have used a 
linter for typechecking (Python is doing this) but the benefits of compile-time 
typechecking affect a large number of programs and so we decided to ship with 
batteries included.

The scoped visibility is like the type system.  It is a compile-time check that 
is used to catch threading, information disclosure, encapsulation violation, or 
similar bugs.  These are problems that affect a large number of programs, we 
should ship with batteries included.

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

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

[Drew Crawford via swift-evolution]

I'm curious to hear what issue your client had with you using many frameworks 
that static linking doesn't solve.

The issue here is the number of frameworks that the user drags and drops into 
Xcode.  Most libraries ship as a single framework, see this page for a typical 
example of what the installation documentation for this process generally looks 
like.

>From a user POV, there is no difference between dragging 4 frameworks and 
>dragging 4 .a libraries.  Actually, the .a case is worse in Swift because in 
>addition to object code (.a) we have .swiftmodule, .swiftdoc, and .modulemap.  
>So that's a lot of files to drag.

I have been involved in generating solutions for this problem in other areas 
(see the atbin standard for example) but none of them are supported by Xcode.

Finally, static linking has nothing to do with visibility or the problems of 
exposing these frameworks as public API.

I don't see why submodules could not profit from WMO: the module is still 
compiled all together. Submodules are simply a scoping/hiding mechanism.

Then you will be surprised to hear that this is a subject of some debate.  
Relevant thread.

That looks like a very corner case. I haven't yet found myself in the case 
where I needed multiple versions of a code base in a same product (binary, 
framework, application)

There are 253 pages of search results for "duplicate symbol" on StackOverflow.  
Compare with 48 pages on fileprivate.  It is quite clear which is the more 
complicated feature.

It would be very strange to me if they were independent libraries: what would 
different them from modules then?

The organization of object code on the filesystem does not necessarily have any 
relationship to "submodules the philosophical construct".

But at the same time, we can't write and review proposals with no regard for 
future proposals coming down the road or we end up with a clunky language.

I'm not aware of evidence any submodule proposal is actually coming.  For 
example here is the only authoritative statement of the feature, "slated" for 
Swift 1.0 , a giant warning that we do not even have a design, and the doc 
mostly consists of questions for how the feature should work.

A scoped access modifier on the other hand is a feature that was designed, is 
implemented, and is now widely used. What you are suggesting is we should throw 
it away because at any moment a bird could appear in the bush.

But we've waited for that bird for 3 releases.  Rather, if that bird were to 
appear, we could then study whether or not it solves all the problems of the 
bird in our hand, or whether it does not.  But that hypothetical is quite far 
from the present circumstance.
On March 23, 2017 at 2:02:25 PM, David Hart (da...@hartbit.com) wrote:



On 23 Mar 2017, at 16:49, Drew Crawford  wrote:




On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote:

> We will get static linking at some point in the near future.
Static linking does not fix this issue. Just change "framework" to ".a".

I'm curious to hear what issue your client had with you using many frameworks 
that static linking doesn't solve.

> If we wait until we get submodules, we won't be able to revisit. This is 
> probably our last chance to "remove" a feature. Submodules can always add 
> features down the way.
Maybe submodules will solve this issue, maybe not.  But submodules are *much* 
more complex than scoped access:

* Performance.  This is hot code we compile with WMO.  Moving it into a 
submodule could reduce visibility for optimization in a way that causes a 
performance regression.  In particular, we know that specialization of T is a 
performance requirement, it isn't clear whether that would be preserved.  Does 
WMO provide the same visibility across submodules?  Nobody knows.

I don't see why submodules could not profit from WMO: the module is still 
compiled all together. Submodules are simply a scoping/hiding mechanism.
* Namespacing.  It's possible that one program may ship 3-4 versions of this 
code because each dependency has a slightly different version under our current 
samizdat process.  It is not clear whether submodules would avoid the 
"duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned about a 
related "duplicate functions" problem involved with private today, doubling 
down on that is not a good idea.

That looks like a very corner case. I haven't yet found myself in the case 
where I needed multiple versions of a code base in a same product (binary, 
framework, application)
* It is not clear whether submodules are from an objectcode point of view 
merged into the parent library or kept as individual libraries

It would be very strange to me if they were independent libraries: what would 
different them from modules then? No other language I've used works that way.
* It is not clear from a .swiftmodule point of view whether submodules are 
merged into the parent module or 

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

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> On 23 Mar 2017, at 16:49, Drew Crawford  > wrote:
> 
>> 
>> 
>> 
>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com 
>> ) wrote:
>> 
>>> > We will get static linking at some point in the near future.
>> 
>> Static linking does not fix this issue. Just change "framework" to ".a".
>> 
> I'm curious to hear what issue your client had with you using many frameworks 
> that static linking doesn't solve.
> 
>>> > If we wait until we get submodules, we won't be able to revisit. This is 
>>> > probably our last chance to "remove" a feature. Submodules can always add 
>>> > features down the way.
>> 
>> Maybe submodules will solve this issue, maybe not.  But submodules are 
>> *much* more complex than scoped access:
>> 
>> * Performance.  This is hot code we compile with WMO.  Moving it into a 
>> submodule could reduce visibility for optimization in a way that causes a 
>> performance regression.  In particular, we know that specialization of T is 
>> a performance requirement, it isn't clear whether that would be preserved.  
>> Does WMO provide the same visibility across submodules?  Nobody knows.
>> 
> I don't see why submodules could not profit from WMO: the module is still 
> compiled all together. Submodules are simply a scoping/hiding mechanism.
>> * Namespacing.  It's possible that one program may ship 3-4 versions of this 
>> code because each dependency has a slightly different version under our 
>> current samizdat process.  It is not clear whether submodules would avoid 
>> the "duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned 
>> about a related "duplicate functions" problem involved with private today, 
>> doubling down on that is not a good idea.
>> 
> That looks like a very corner case. I haven't yet found myself in the case 
> where I needed multiple versions of a code base in a same product (binary, 
> framework, application)
>> * It is not clear whether submodules are from an objectcode point of view 
>> merged into the parent library or kept as individual libraries
>> 
> It would be very strange to me if they were independent libraries: what would 
> different them from modules then? No other language I've used works that way.
>> * It is not clear from a .swiftmodule point of view whether submodules are 
>> merged into the parent module or distributed as .swiftmodules / .swiftdocs
>> 
>> * Not clear how much ABI impact there is from submodules at a time when we 
>> are supposed to be trying to stabilize it
>> 
>> I would love to believe that a proposal on submodules will come through 
>> having solutions to all these issues and many more, then we will implement 
>> it and all sing kumbayah.  But we are a long distance from that, and it may 
>> never happen at all, certainly we cannot evaluate proposals that haven't 
>> been written.  Meanwhile we have a solution in the hand.
>> 
> But at the same time, we can't write and review proposals with no regard for 
> future proposals coming down the road or we end up with a clunky language.

Or we can just wait until access control and / or submodules are part of a 
release theme and address these issues more holistically.  As I have said 
before, the details of the submodule design we eventually end up with could 
influence what problems people want access control to address (or not address). 
 It’s possible that we could end up with a design that allows us to eliminate 
`fileprivate` instead of `private` if we feel we must eliminate one of them.  
Right now we just don’t know enough to say for sure.

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

[David Hart via swift-evolution]

> On 23 Mar 2017, at 16:49, Drew Crawford  wrote:
> 
> 
> 
> 
>> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote:
>> 
>> > We will get static linking at some point in the near future.
> 
> Static linking does not fix this issue. Just change "framework" to ".a".
> 
I'm curious to hear what issue your client had with you using many frameworks 
that static linking doesn't solve.

>> > If we wait until we get submodules, we won't be able to revisit. This is 
>> > probably our last chance to "remove" a feature. Submodules can always add 
>> > features down the way.
> 
> Maybe submodules will solve this issue, maybe not.  But submodules are *much* 
> more complex than scoped access:
> 
> * Performance.  This is hot code we compile with WMO.  Moving it into a 
> submodule could reduce visibility for optimization in a way that causes a 
> performance regression.  In particular, we know that specialization of T is a 
> performance requirement, it isn't clear whether that would be preserved.  
> Does WMO provide the same visibility across submodules?  Nobody knows.
> 
I don't see why submodules could not profit from WMO: the module is still 
compiled all together. Submodules are simply a scoping/hiding mechanism.
> * Namespacing.  It's possible that one program may ship 3-4 versions of this 
> code because each dependency has a slightly different version under our 
> current samizdat process.  It is not clear whether submodules would avoid the 
> "duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned about a 
> related "duplicate functions" problem involved with private today, doubling 
> down on that is not a good idea.
> 
That looks like a very corner case. I haven't yet found myself in the case 
where I needed multiple versions of a code base in a same product (binary, 
framework, application)
> * It is not clear whether submodules are from an objectcode point of view 
> merged into the parent library or kept as individual libraries
> 
It would be very strange to me if they were independent libraries: what would 
different them from modules then? No other language I've used works that way.
> * It is not clear from a .swiftmodule point of view whether submodules are 
> merged into the parent module or distributed as .swiftmodules / .swiftdocs
> 
> * Not clear how much ABI impact there is from submodules at a time when we 
> are supposed to be trying to stabilize it
> 
> I would love to believe that a proposal on submodules will come through 
> having solutions to all these issues and many more, then we will implement it 
> and all sing kumbayah.  But we are a long distance from that, and it may 
> never happen at all, certainly we cannot evaluate proposals that haven't been 
> written.  Meanwhile we have a solution in the hand.
> 
But at the same time, we can't write and review proposals with no regard for 
future proposals coming down the road or we end up with a clunky language.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

To what extent could your need for safety be satisfied by (a) giving the 
property a long, unique name like `unsafeUnsynchronizedT`, and (b) writing a 
very small unit test/shell script/Perl script which makes sure references to 
that very unique name only appear between the two "MARK:" comments?

-- 
Brent Royal-Gordon
Sent from my iPhone

> On Mar 23, 2017, at 10:11 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> I can't go into detail in public, but I can say that we did a postmortem on 
>> a large lost sale and the customer specifically cited the number of 
>> frameworks in our product as an integration barrier for them.  Most iOS SDKs 
>> are distributed as a single framework and so with that backdrop the friction 
>> makes more sense.
>> 
>> As a result of that I have about 5 bugs open on how to reduce our framework 
>> footprint so our tools are easier for our users to integrate.  There are a 
>> variety of solutions we use on that, what you see here is one of the saner 
>> ones, believe it or not.
>> 
>> Whether or not the technical requirement makes sense to you, the business 
>> case is very clear.  So clear that if scoped were removed we would almost 
>> certainly keep the file and its potential threading bugs, over promoting a 
>> new framework.  Sales >> code, unfortunately.
>> 
> Oh, come on — that sounds like removing new private would threaten your 
> existence… in this case, afaics a simple search & replace (private -> 
> fileprivate) works just fine.
> You may not like that solution, but others might not even notice the 
> difference. 
> Imho the importance of SE-25 has been exaggerated tremendously before it was 
> added, and the same seems to happen now, when its removal is discussed.
> 
> We shouldn't overdramatise this question, and don't invent arguments to 
> support partialities:
> Access control worked fine in Swift 2, and fileprivate didn't increase the 
> complexity of the language in a way that makes it impossible to teach it.
> 
> There are arguments for both positions, and they are valid — but there is a 
> huge variance in the perceived importance, and discussion has only very 
> limited effect on this.
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Tino Heth via swift-evolution]

> I can't go into detail in public, but I can say that we did a postmortem on a 
> large lost sale and the customer specifically cited the number of frameworks 
> in our product as an integration barrier for them.  Most iOS SDKs are 
> distributed as a single framework and so with that backdrop the friction 
> makes more sense.
> 
> As a result of that I have about 5 bugs open on how to reduce our framework 
> footprint so our tools are easier for our users to integrate.  There are a 
> variety of solutions we use on that, what you see here is one of the saner 
> ones, believe it or not.
> 
> Whether or not the technical requirement makes sense to you, the business 
> case is very clear.  So clear that if scoped were removed we would almost 
> certainly keep the file and its potential threading bugs, over promoting a 
> new framework.  Sales >> code, unfortunately.
> 
Oh, come on — that sounds like removing new private would threaten your 
existence… in this case, afaics a simple search & replace (private -> 
fileprivate) works just fine.
You may not like that solution, but others might not even notice the 
difference. 
Imho the importance of SE-25 has been exaggerated tremendously before it was 
added, and the same seems to happen now, when its removal is discussed.

We shouldn't overdramatise this question, and don't invent arguments to support 
partialities:
Access control worked fine in Swift 2, and fileprivate didn't increase the 
complexity of the language in a way that makes it impossible to teach it.

There are arguments for both positions, and they are valid — but there is a 
huge variance in the perceived importance, and discussion has only very limited 
effect on this.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Mar 23, 2017, at 10:51 AM, Andrey Fidrya via swift-evolution 
>  wrote:
> 
>> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution 
>>  wrote:
>> I strongly prefer that “private” should mean “visible in the current file”.
>> I am ambivalent between eliminating the scoped access level or renaming it 
>> “scoped”, as long as “private” once more denotes file-level visibility.
> 
> Imo opinions are split 50/50 on whether access levels should be file based or 
> type based, it's endless debate.
> What are the downsides of covering both cases? I.e. making private "visible 
> in the current file and type extensions".
> This concept is not that hard to teach and doesn't require complex and 
> syntactically verbose access level systems.

I can’t speak for others, but I want scoped access not type-based access.  
Type-based access control solves different problems than scoped access control 
and isn’t under discussion in this review.

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

[Andrey Fidrya via swift-evolution]

> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> I strongly prefer that “private” should mean “visible in the current file”.
> I am ambivalent between eliminating the scoped access level or renaming it 
> “scoped”, as long as “private” once more denotes file-level visibility.

Imo opinions are split 50/50 on whether access levels should be file based or 
type based, it's endless debate.
What are the downsides of covering both cases? I.e. making private "visible in 
the current file and type extensions".
This concept is not that hard to teach and doesn't require complex and 
syntactically verbose access level systems.

Andrey

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

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

[Drew Crawford via swift-evolution]

On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com) wrote:

> We will get static linking at some point in the near future.
Static linking does not fix this issue. Just change "framework" to ".a".

> If we wait until we get submodules, we won't be able to revisit. This is 
> probably our last chance to "remove" a feature. Submodules can always add 
> features down the way.
Maybe submodules will solve this issue, maybe not.  But submodules are *much* 
more complex than scoped access:

* Performance.  This is hot code we compile with WMO.  Moving it into a 
submodule could reduce visibility for optimization in a way that causes a 
performance regression.  In particular, we know that specialization of T is a 
performance requirement, it isn't clear whether that would be preserved.  Does 
WMO provide the same visibility across submodules?  Nobody knows.

* Namespacing.  It's possible that one program may ship 3-4 versions of this 
code because each dependency has a slightly different version under our current 
samizdat process.  It is not clear whether submodules would avoid the 
"duplicate symbols" issue from C/ObjC.  Xiaodi seems quite concerned about a 
related "duplicate functions" problem involved with private today, doubling 
down on that is not a good idea.

* It is not clear whether submodules are from an objectcode point of view 
merged into the parent library or kept as individual libraries

* It is not clear from a .swiftmodule point of view whether submodules are 
merged into the parent module or distributed as .swiftmodules / .swiftdocs

* Not clear how much ABI impact there is from submodules at a time when we are 
supposed to be trying to stabilize it

I would love to believe that a proposal on submodules will come through having 
solutions to all these issues and many more, then we will implement it and all 
sing kumbayah.  But we are a long distance from that, and it may never happen 
at all, certainly we cannot evaluate proposals that haven't been written.  
Meanwhile we have a solution in the hand.

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

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

[Drew Crawford via swift-evolution]

It has been expressed in various ways "does anybody actually use scoped 
visibility in the wild" and "what real benefit does it provide to production 
code".

The below file or some estranged stepchild of it appears at least 5 
repositories (that I know of; this is practically a samizdat around here).  The 
scoped access modifier is a significant improvement to the safety of this code 
and by extension the many projects that contain it.

Apologies if this listing is rather tiring.  Many of the "solutions" proposed 
by the anti-private camp sound great in a sentence but fall apart at scale.  
But it is not obvious why this is so to people who do not use the keyword, so I 
can understand why they keep suggesting poor solutions.  Perhaps with a more 
involved listing, it will become more obvious why many of these suggestions do 
not work.  The original is a lot longer; I did reduce it to only the parts that 
seem relevant to this thread.

import Foundation

/**
 This code demonstrates one of the usecases for 'private'.  Adapted from real 
production code, this file exports a threading primitive to the rest of the 
program.
 
 To state it briefly, private is necessary here because we need the following 
visibility nesting to achieve our objective:
 
 ┌───┐
 │PROGRAM/internal                           │
 │                                           │
 │                                           │
 │     ┌───┐ │
 │     │ ThreadsafeWrapperNotifyChanged    │ │
 │     │                                   │ │
 │     │      ┌──┐     │ │
 │     │      │   ThreadsafeWrapper  │     │ │
 │     │      │                      │     │ │
 │     │      │                      │     │ │
 │     │      │          value       │     │ │
 │     │      │                      │     │ │
 │     │      │                      │     │ │
 │     │      └──┘     │ │
 │     │                                   │ │
 │     └───┘ │
 └───┘
 
 In particular:
 
 1.  value a.k.a. "t" must be protected against all potential unsafe access.  
This file is hundreds of lines, auditing the whole thing is very tedious.
 2.  ThreadsafeWrapper is an implementation detail of 
ThreadsafeWrapperNotifyChanged which is not intended for use by other callers.  
To avoid exposing the class to other callers, it must appear in this file.
 3.  This file cannot be made an entire module, because it's actually used as 
part of several projects that are shipped as frameworks, and apparently some 
developers get really annoyed when they have to drag too many frameworks into 
their Xcode project.
 4.  The use of `private` here reduces the "maybe not threadsafe" part of the 
code from 196 lines to 47 lines (a reduction of buggy code of 76%).  In the 
production file from which this example is derived, the reduction is from 423 
lines to 33 lines, or 92%.  A scoped access variable significantly improves the 
threadsafety of this code.

 */

//Define an interface common to both major components
private protocol Threadsafe : class {
    ///the type of the value we are protecting
    associatedtype T
    ///Access the underlying value.
    ///- parameter block: The block that will be passed the protected value.  
The block acts as an exclusive lock; while you're in it, no other consumers 
will be accessing the value.  
    ///- complexity: Coalescing multiple operations into a single block 
improves performance.
    func accessT(_ block: @escaping (T) throws -> K) throws -> K
    ///Mutate the underlying value.
    ///- parameter block: The block that will be passed the protected value.  
The block acts as an exclusive lock; while you're in it, no other consumers 
will be accessing the value.
    ///- complexity: Coalescing multiple operations into a single block 
improves performance.
    func mutateT(_ block: @escaping (inout T) throws -> K) throws -> K
}

///Some convenience accessors for callers that do not need a block-based API to 
get lock semantics / operation coalescing
extension Threadsafe {
    var value : T {
        get {
            var t: T! = nil
            try! accessT({ lt in
                t = lt
            })
            return t
        }
        set {
            try! mutateT({ (lt:inout T) -> () in
                lt = newValue
            })
        }
    }
}

///The core synchronization primitive.  This is a private implementation detail 
of ThreadsafeWrapperNotifyChanged.
//MARK: audit this area begin
private final class ThreadsafeWrapper : Threadsafe {
    /**The value we are protecting.  This value needs to be protected against 
unsafe access from
    1.  This type, if a scoped keyword is available (as shown)
    2.  The entire file, if a scoped keyword is removed.
     Only access this value on the synchronizationQueue.
     */
    private var t: T
    ///The queue that 

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

[Nevin Brackett-Rozinsky via swift-evolution]

I strongly prefer that “private” should mean “visible in the current file”.

I am ambivalent between eliminating the scoped access level or renaming it
“scoped”, as long as “private” once more denotes file-level visibility.

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

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

[Aaron Crespo via swift-evolution]

+1 What is "current private" can be replicated with the new behavior, use
of files, and use of modules.

On Wed, Mar 22, 2017 at 8:59 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 21, 2017, at 15:26, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The kicker is, _it also doesn't work_. Try, for instance:
>
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
>
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
>
> The code above should compile and does not. If I understood correctly the
> explanation from a core team member on this list, it's unclear if it can be
> made to work without changing how mangling works, which I believe impacts
> ABI and is not trivial at all. Thus, (a) even proponents of new `private`
> disagree on one of two key goals stated for new `private`; (b) that goal
> was never accomplished, and making it work is not trivial; (c) no one even
> complained about it, suggesting that it was a low-yield goal in the first
> place.
>
>
> Without commenting on anything else, it is considered a bug that this does
> not work under SE-0025, and it *has* been complained about
>  (though not vigorously, since the
> workaround is trivial), and fixing it would not be an ABI-breaking change
> (because private functions are not part of a module's ABI).
>
> Jordan
>
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Jordan Rose via swift-evolution]

> On Mar 21, 2017, at 15:26, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> The kicker is, _it also doesn't work_. Try, for instance:
> 
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
> 
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
> 
> The code above should compile and does not. If I understood correctly the 
> explanation from a core team member on this list, it's unclear if it can be 
> made to work without changing how mangling works, which I believe impacts ABI 
> and is not trivial at all. Thus, (a) even proponents of new `private` 
> disagree on one of two key goals stated for new `private`; (b) that goal was 
> never accomplished, and making it work is not trivial; (c) no one even 
> complained about it, suggesting that it was a low-yield goal in the first 
> place.

Without commenting on anything else, it is considered a bug that this does not 
work under SE-0025, and it has been complained about 
 (though not vigorously, since the 
workaround is trivial), and fixing it would not be an ABI-breaking change 
(because private functions are not part of a module's ABI).

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

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

[Kevin Ballard via swift-evolution]

On Wed, Mar 22, 2017, at 01:58 PM, Kevin Ballard wrote:

> On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote:
>>  * What is your evaluation of the proposal?
> 

> Huge -1, and I agree strongly with Drew Crockford's emails on
> this topic.


My apologies, Drew. It's Drew Crawford.



-Kevin Ballard


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

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

[Kevin Ballard via swift-evolution]

On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote:
>  * What is your evaluation of the proposal?


Huge -1, and I agree strongly with Drew Crockford's emails on
this topic.


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

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

[Robert Hedin via swift-evolution]

   - What is your evaluation of the proposal?

+1

I'm generally a proponent of scoped access control and have been torn over
this proposal. What finally pushed me over the edge has been the time I've
taken to review others code. I've got a team of about 32 iOS developers and
their code shows a heavy lean toward using 'fileprivate' over 'private'.
When  I dig into it to determine why, the most common response has been
something along the lines of "I'm not sure what the difference is". In at
least one case, the developer said "well, I usually try 'private' until it
won't compile, then I just change things to 'fileprivate'". Granted this is
an education and training issue, but with other languages the primary
access modifiers are pretty easy to understand. Intermixing scoped access
vs file based protections seems to cause unneeded confusion that I suspect
was increased  after running the migrator.

I like elegance and I like the compiler catching things for me, but at the
end of the day I'd rather see things simple and easy to understand and
explain. To that end, I'd prefer to revert to the previous behavior while
we decide on a comprehensive solution based on the learnings from this
effort.



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

Yes.


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

Yes. Increased simplicity reduces overall cognitive load on the developer.


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

The access control modifiers in Swift are somewhat different than most
other languages I've used, so a comparison between C# or Java seems forced.


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

Several hours, both reviewing internal affected code, the proposal, and
these discussions.

rob.


On Mon, Mar 20, 2017 at 7:54 PM, Douglas Gregor  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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>


-- 
*Robert **Hedin  *|Dir Software Engineering
*w:* 770-226-2650  *e:* robert.he...@weather.com
 
 
 
 
 
 
 
 

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

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

[Ben Rimmington via swift-evolution]

> On 22 Mar 2017, at 03:16, Xiaodi Wu wrote:
> 
>> On Tue, Mar 21, 2017 at 9:38 PM, Matthew Johnson wrote:
>> 
>>> On Mar 21, 2017, at 9:28 PM, Xiaodi Wu wrote:
>>> 
>>> And couldn't this be enforced by a linter feature that warns if a private 
>>> member beginning with _ is accessed outside of scope?
>> 
>> I don’t like to use naming conventions and linters to catch things that 
>> belong in the language proper.  Hasn’t the community agreed that we don’t 
>> want dialects of Swift?
> 
> Very agreed. But is it a "dialect" when it's spoken by the standard library?

It's a shame the standard library can't use `fileprivate` and `private`, but 
the SDK overlays have the following usage:

$ egrep --include *.swift --recursive '\bfileprivate\b' ./stdlib/public/SDK
[47 results]

$ egrep --include *.swift --recursive '\bprivate\b' ./stdlib/public/SDK
[65 results, 8 of which are at file scope]

-- Ben

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

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

[Rob Mayoff via swift-evolution]

On Tue, Mar 21, 2017 at 10:51 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:
>
> The bug *does not affect what people use private for,* and so it *does not
> affect anything in real-world use.* It’s less “the Finder makes your files
> disappear on a regular basis” and more “if you give a file a name with a
> very specific sequence of Plane 2 Unicode characters, and then set the
> ‘Stationery' bit in the Finder flags, the icon doesn’t draw correctly.”
> It’s a bug, and it should be fixed, but it’s not even close to being a
> show-stopper.
>

This, 100%.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 10:42 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu > > wrote:
> 
>> 
>> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka >> > wrote:
>>> 
 On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > wrote:
 
 On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > wrote:
> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  > wrote:
 
> 
> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> So, if four/five access modifiers are too many, which one is carrying 
>> the least weight? Which one could be removed to simplify the scheme 
>> while maintaining the most expressiveness? Which one doesn't fulfill 
>> even its own stated goals? Well, one of the key goals of `private` was 
>> to allow members to be encapsulated within an extension, hidden even 
>> from the type being extended (and vice versa for members defined in the 
>> type). It says so in the first sentence of SE-0025. As seen above in my 
>> discussion with Charles Srstka, even supporters of `private` disagree 
>> with that motivation to begin with. The kicker is, _it also doesn't 
>> work_. Try, for instance:
>> 
>> ```
>> struct Foo {
>>   private var bar: Int { return 42 }
>> }
>> 
>> extension Foo {
>>   private var bar: Int { return 43 }
>> }
>> ```
>> 
>> The code above should compile and does not. If I understood correctly 
>> the explanation from a core team member on this list, it's unclear if it 
>> can be made to work without changing how mangling works, which I believe 
>> impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
>> `private` disagree on one of two key goals stated for new `private`; (b) 
>> that goal was never accomplished, and making it work is not trivial; (c) 
>> no one even complained about it, suggesting that it was a low-yield goal 
>> in the first place.
> 
> Multiple people have already brought up cases in which they are using 
> ‘private’. The repeated mention of another, unrelated use case that was 
> mentioned in the SE-0025 proposal does not invalidate the real-world use 
> cases which have been presented. In fact, it rather makes it appear as if 
> the motivation to remove ‘private’ is based on a strange invocation of 
> the appeal-to-authority fallacy, rather than an actual improvement to the 
> language.
> 
> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
> implemented. And as I said above, IIUC, it cannot be fully implemented 
> without ripping out a lot of mangling code that is unlikely to be ripped 
> out before Swift 4. _And there is no evidence that anyone cares about 
> this flaw; in fact, you are saying as much, that you do not care at all!_ 
> If this is not sufficient indication that the design of SE-0025 does not 
> fit with the overall direction of Swift, what would be?
 
 Because there are other uses cases for ‘private', *not* involving 
 extensions, which I *do* care about. The fact that part of the proposal 
 was badly written (and really, that’s all this is
 
 Huh? The code above *should compile*--that is a primary aim for SE-0025. 
 It does not compile and there is not a timeline (afaict) for its 
 compiling. It does not bother you that the 25th proposal considered in the 
 Swift evolution process, already once revised, is not fully implemented 
 and may never be?
>>> 
>>> Someone finding a bug/oversight in the compiler behavior does not compel me 
>>> to throw out the baby with the bathwater, no.
>>> 
>>> You're not hearing the argument. No one "accidentally" included this design 
>>> as part of SE-0025; it's sentence number one.
>> 
>> Or not. Here’s the actual text of the introductory paragraph:
>> 
>> "Scoped access level allows hiding implementation details of a class or a 
>> class extension at the class/extension level, instead of a file. It is a 
>> concise expression of the intent that a particular part of a class 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu  wrote:
>
>
> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka 
>  wrote:
>
>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu  wrote:
>>
>>
>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > > wrote:
>>
>>>
>>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>>>
>>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka >> om> wrote:
>>>
 On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:


 On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka  wrote:

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> So, if four/five access modifiers are too many, which one is carrying
> the least weight? Which one could be removed to simplify the scheme while
> maintaining the most expressiveness? Which one doesn't fulfill even its 
> own
> stated goals? Well, one of the key goals of `private` was to allow members
> to be encapsulated within an extension, hidden even from the type being
> extended (and vice versa for members defined in the type). It says so in
> the first sentence of SE-0025. As seen above in my discussion with Charles
> Srstka, even supporters of `private` disagree with that motivation to 
> begin
> with. The kicker is, _it also doesn't work_. Try, for instance:
>
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
>
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
>
> The code above should compile and does not. If I understood correctly
> the explanation from a core team member on this list, it's unclear if it
> can be made to work without changing how mangling works, which I believe
> impacts ABI and is not trivial at all. Thus, (a) even proponents of new
> `private` disagree on one of two key goals stated for new `private`; (b)
> that goal was never accomplished, and making it work is not trivial; (c) 
> no
> one even complained about it, suggesting that it was a low-yield goal in
> the first place.
>
>
> Multiple people have already brought up cases in which they are using
> ‘private’. The repeated mention of another, unrelated use case that was
> mentioned in the SE-0025 proposal does not invalidate the real-world use
> cases which have been presented. In fact, it rather makes it appear as if
> the motivation to remove ‘private’ is based on a strange invocation of the
> appeal-to-authority fallacy, rather than an actual improvement to the
> language.
>

 I'm not sure how to respond to this. SE-0025, as designed, is not fully
 implemented. And as I said above, IIUC, it cannot be fully implemented
 without ripping out a lot of mangling code that is unlikely to be ripped
 out before Swift 4. _And there is no evidence that anyone cares about this
 flaw; in fact, you are saying as much, that you do not care at all!_ If
 this is not sufficient indication that the design of SE-0025 does not fit
 with the overall direction of Swift, what would be?


 Because there are other uses cases for ‘private', *not* involving
 extensions, which I *do* care about. The fact that part of the proposal was
 badly written (and really, that’s all this is

>>>
>>> Huh? The code above *should compile*--that is a primary aim for SE-0025.
>>> It does not compile and there is not a timeline (afaict) for its compiling.
>>> It does not bother you that the 25th proposal considered in the Swift
>>> evolution process, already once revised, is not fully implemented and may
>>> never be?
>>>
>>>
>>> Someone finding a bug/oversight in the compiler behavior does not compel
>>> me to throw out the baby with the bathwater, no.
>>>
>>
>> You're not hearing the argument. No one "accidentally" included this
>> design as part of SE-0025; it's sentence number one.
>>
>>
>> Or not. Here’s the actual text of the introductory paragraph:
>>
>> "Scoped access level allows hiding implementation details of a class or a
>> class extension at the class/extension level, instead of a file. It is a
>> concise expression of the intent that a particular part of a class or
>> extension definition is there only to implement a public API for other
>> classes or extensions and must not be used directly anywhere outside of the
>> scope of the class or the extension.”
>>
>> So here we have “class or extension”, or some variant thereof, five
>> separate times. It honestly reads like it originally just said “class”, and
>> the author systematically went through it and added “or extension” to each
>> of them to make sure his/her bases were 

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

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > > wrote:
>> 
>>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > wrote:
>>> 
 
 On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote:
> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> So, if four/five access modifiers are too many, which one is carrying the 
> least weight? Which one could be removed to simplify the scheme while 
> maintaining the most expressiveness? Which one doesn't fulfill even its 
> own stated goals? Well, one of the key goals of `private` was to allow 
> members to be encapsulated within an extension, hidden even from the type 
> being extended (and vice versa for members defined in the type). It says 
> so in the first sentence of SE-0025. As seen above in my discussion with 
> Charles Srstka, even supporters of `private` disagree with that 
> motivation to begin with. The kicker is, _it also doesn't work_. Try, for 
> instance:
> 
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
> 
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
> 
> The code above should compile and does not. If I understood correctly the 
> explanation from a core team member on this list, it's unclear if it can 
> be made to work without changing how mangling works, which I believe 
> impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
> `private` disagree on one of two key goals stated for new `private`; (b) 
> that goal was never accomplished, and making it work is not trivial; (c) 
> no one even complained about it, suggesting that it was a low-yield goal 
> in the first place.
 
 Multiple people have already brought up cases in which they are using 
 ‘private’. The repeated mention of another, unrelated use case that was 
 mentioned in the SE-0025 proposal does not invalidate the real-world use 
 cases which have been presented. In fact, it rather makes it appear as if 
 the motivation to remove ‘private’ is based on a strange invocation of the 
 appeal-to-authority fallacy, rather than an actual improvement to the 
 language.
 
 I'm not sure how to respond to this. SE-0025, as designed, is not fully 
 implemented. And as I said above, IIUC, it cannot be fully implemented 
 without ripping out a lot of mangling code that is unlikely to be ripped 
 out before Swift 4. _And there is no evidence that anyone cares about this 
 flaw; in fact, you are saying as much, that you do not care at all!_ If 
 this is not sufficient indication that the design of SE-0025 does not fit 
 with the overall direction of Swift, what would be?
>>> 
>>> Because there are other uses cases for ‘private', *not* involving 
>>> extensions, which I *do* care about. The fact that part of the proposal was 
>>> badly written (and really, that’s all this is
>>> 
>>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>>> does not compile and there is not a timeline (afaict) for its compiling. It 
>>> does not bother you that the 25th proposal considered in the Swift 
>>> evolution process, already once revised, is not fully implemented and may 
>>> never be?
>> 
>> Someone finding a bug/oversight in the compiler behavior does not compel me 
>> to throw out the baby with the bathwater, no.
>> 
>> You're not hearing the argument. No one "accidentally" included this design 
>> as part of SE-0025; it's sentence number one.
> 
> Or not. Here’s the actual text of the introductory paragraph:
> 
> "Scoped access level allows hiding implementation details of a class or a 
> class extension at the class/extension level, instead of a file. It is a 
> concise expression of the intent that a particular part of a class or 
> extension definition is there only to implement a public API for other 
> classes or extensions and must not be used directly anywhere outside of the 
> scope of the class or the extension.”
> 
> So here we have “class or extension”, or some variant thereof, five separate 
> times. It honestly reads like it 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:38 PM, Matthew Johnson 
wrote:

>
> On Mar 21, 2017, at 9:28 PM, Xiaodi Wu  wrote:
>
> On Tue, Mar 21, 2017 at 8:31 PM, Matthew Johnson 
> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford 
>> wrote:
>>
>>> I am confused by this response. An argument in _support_ of new
>>> `private` was that it is more in line with expectations of users coming
>>> from other languages. In other some cases, such an argument might have its
>>> place. However, as others have pointed out on this list, those other
>>> languages don't have facilities like Swift's extensions, and therefore it
>>> was not a very strong argument for new `private` to say that it better
>>> aligns with user expectations coming from other languages.
>>>
>>> The underlying issue here (which I have now identified, thanks!) is what
>>> motivates the use of extensions.  That question predates proposals, but the
>>> Swift book provides the following motivation, which I have numbered for
>>> ease of reference:
>>>
>>> 1. Extensions add new functionality to an existing class, structure,
>>> enumeration, or protocol type.
>>>
>>> 2. This includes the ability to extend types for which you do not have
>>> access to the original source code (known as retroactive modeling).
>>>
>>> 3. Extensions are similar to categories in Objective-C.
>>>
>>> It seems to me this motivation contemplates use “at some distance”, that
>>> is we intend to create some semantically meaningful separation between the
>>> declaration and the extension(s).  If we did not we could use MARK or some
>>> other comment-based scheme to organize our class.
>>>
>>> 2 is explicitly at great distance, so we know the distance motivation is
>>> well within scope.  1 refers to “an existing” type which implies a certain
>>> level of functionality in the unextended type, and not merely a partial
>>> implementation in the unextended type.  The record on 3 is more mixed (ObjC
>>> programmers do occasionally use categories “closely-held” to group a few
>>> methods together).  However ObjC also has the “distance” tradition:
>>> categories cannot introduce new storage even when this is technically
>>> trivial (within the same compilation unit for example), and this tradition
>>> was continued under Swift with the new ABI.
>>>
>>> What I am suggesting is that the primary design purpose of an extension
>>> is to create semantic distance between a declaration and the functionality
>>> being added.
>>>
>>
>> I'm not sure it is necessary for extensions to have a "primary design
>> purpose." They serve many purposes. One use I have for them is as follows:
>>
>> ```
>> struct A {
>>   // Stuff here constitutes the "raison d'etre" for A.
>> }
>>
>> extension A : B {
>>   // In the course of implementing `A`, I have discovered that
>>   // `A` can fulfill the semantic guarantees of `B`, and in fact
>>   // fulfills most of them already.
>>   //
>>   // So, I conform to B, as in so doing there are some practical
>>   // advantages, such as gaining some default implementations.
>>   //
>>   // But, to conform, I may need to implement some methods
>>   // not really essential for a functional `A`, but required nonetheless
>>   // to conform to `B`.
>>   //
>>   // I implement them here in an extension; in so doing, I express
>>   // the idea that I have, after implementing `A`, discovered its
>>   // conformance to `B`, and I am here supplying the remaining
>>   // implementations necessary for that conformance.
>>   //
>>   // That is, if `B` did not exist, neither would these functions here.
>>   // But there may be some requirements of `B` that would be
>>   // implemented in `A` whether or not `B` exists.
>>   // Those are implemented above, in `struct A { ... }`.
>> }
>> ```
>>
>> I find this to be an eloquent way to separate concerns. It is a common
>> pattern encouraged by code I admire written by others more skilled than me
>> in Swift.
>>
>> A mechanism to hide variables from extensions is something that
>>> *furthers* this design goal of extensions, rather than contradicts it.
>>>
>>
>> This, I suppose, is an argument for you to take up with Charles.
>>
>>
>>> I understand that some people use extensions as sort of an imitation
>>> “partial class” but they simply aren’t (no storage) and we should introduce
>>> a new feature if we want to have them.
>>>
>>> A core team member (I'm blanking on who) has pointed out that, in the
>>> end, the only necessary access modifiers are public and not public (spelled
>>> "internal" in Swift).
>>>
>>>
>>> It is not clear to me how this squares with the decision in SE-0025 that
>>> other access modifiers were necessary.  Can you clarify?
>>>
>>
>> Why do you think SE-0025 decided that other access modifiers are
>> 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu  wrote:
>
>
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka 
>  wrote:
>
>>
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>>
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>>>
>>>
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> om> wrote:
>>>
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:


 So, if four/five access modifiers are too many, which one is carrying
 the least weight? Which one could be removed to simplify the scheme while
 maintaining the most expressiveness? Which one doesn't fulfill even its own
 stated goals? Well, one of the key goals of `private` was to allow members
 to be encapsulated within an extension, hidden even from the type being
 extended (and vice versa for members defined in the type). It says so in
 the first sentence of SE-0025. As seen above in my discussion with Charles
 Srstka, even supporters of `private` disagree with that motivation to begin
 with. The kicker is, _it also doesn't work_. Try, for instance:

 ```
 struct Foo {
   private var bar: Int { return 42 }
 }

 extension Foo {
   private var bar: Int { return 43 }
 }
 ```

 The code above should compile and does not. If I understood correctly
 the explanation from a core team member on this list, it's unclear if it
 can be made to work without changing how mangling works, which I believe
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new
 `private` disagree on one of two key goals stated for new `private`; (b)
 that goal was never accomplished, and making it work is not trivial; (c) no
 one even complained about it, suggesting that it was a low-yield goal in
 the first place.


 Multiple people have already brought up cases in which they are using
 ‘private’. The repeated mention of another, unrelated use case that was
 mentioned in the SE-0025 proposal does not invalidate the real-world use
 cases which have been presented. In fact, it rather makes it appear as if
 the motivation to remove ‘private’ is based on a strange invocation of the
 appeal-to-authority fallacy, rather than an actual improvement to the
 language.

>>>
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully
>>> implemented. And as I said above, IIUC, it cannot be fully implemented
>>> without ripping out a lot of mangling code that is unlikely to be ripped
>>> out before Swift 4. _And there is no evidence that anyone cares about this
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If
>>> this is not sufficient indication that the design of SE-0025 does not fit
>>> with the overall direction of Swift, what would be?
>>>
>>>
>>> Because there are other uses cases for ‘private', *not* involving
>>> extensions, which I *do* care about. The fact that part of the proposal was
>>> badly written (and really, that’s all this is
>>>
>>
>> Huh? The code above *should compile*--that is a primary aim for SE-0025.
>> It does not compile and there is not a timeline (afaict) for its compiling.
>> It does not bother you that the 25th proposal considered in the Swift
>> evolution process, already once revised, is not fully implemented and may
>> never be?
>>
>>
>> Someone finding a bug/oversight in the compiler behavior does not compel
>> me to throw out the baby with the bathwater, no.
>>
>
> You're not hearing the argument. No one "accidentally" included this
> design as part of SE-0025; it's sentence number one.
>
>
> Or not. Here’s the actual text of the introductory paragraph:
>
> "Scoped access level allows hiding implementation details of a class or a
> class extension at the class/extension level, instead of a file. It is a
> concise expression of the intent that a particular part of a class or
> extension definition is there only to implement a public API for other
> classes or extensions and must not be used directly anywhere outside of the
> scope of the class or the extension.”
>
> So here we have “class or extension”, or some variant thereof, five
> separate times. It honestly reads like it originally just said “class”, and
> the author systematically went through it and added “or extension” to each
> of them to make sure his/her bases were covered.
>

The meaning of that sentence is made quite clear by the example in code
given in that proposal:

```

class A {
   private var counter = 0

   // public API that hides the internal state   func incrementCount()
{ ++counter }

   // hidden API, not visible outside of this 

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

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 10:02 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson  > wrote:
> 
>> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > > wrote:
>> 
>>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > wrote:
>>> 
 
 On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote:
> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> So, if four/five access modifiers are too many, which one is carrying the 
> least weight? Which one could be removed to simplify the scheme while 
> maintaining the most expressiveness? Which one doesn't fulfill even its 
> own stated goals? Well, one of the key goals of `private` was to allow 
> members to be encapsulated within an extension, hidden even from the type 
> being extended (and vice versa for members defined in the type). It says 
> so in the first sentence of SE-0025. As seen above in my discussion with 
> Charles Srstka, even supporters of `private` disagree with that 
> motivation to begin with. The kicker is, _it also doesn't work_. Try, for 
> instance:
> 
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
> 
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
> 
> The code above should compile and does not. If I understood correctly the 
> explanation from a core team member on this list, it's unclear if it can 
> be made to work without changing how mangling works, which I believe 
> impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
> `private` disagree on one of two key goals stated for new `private`; (b) 
> that goal was never accomplished, and making it work is not trivial; (c) 
> no one even complained about it, suggesting that it was a low-yield goal 
> in the first place.
 
 Multiple people have already brought up cases in which they are using 
 ‘private’. The repeated mention of another, unrelated use case that was 
 mentioned in the SE-0025 proposal does not invalidate the real-world use 
 cases which have been presented. In fact, it rather makes it appear as if 
 the motivation to remove ‘private’ is based on a strange invocation of the 
 appeal-to-authority fallacy, rather than an actual improvement to the 
 language.
 
 I'm not sure how to respond to this. SE-0025, as designed, is not fully 
 implemented. And as I said above, IIUC, it cannot be fully implemented 
 without ripping out a lot of mangling code that is unlikely to be ripped 
 out before Swift 4. _And there is no evidence that anyone cares about this 
 flaw; in fact, you are saying as much, that you do not care at all!_ If 
 this is not sufficient indication that the design of SE-0025 does not fit 
 with the overall direction of Swift, what would be?
>>> 
>>> Because there are other uses cases for ‘private', *not* involving 
>>> extensions, which I *do* care about. The fact that part of the proposal was 
>>> badly written (and really, that’s all this is
>>> 
>>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>>> does not compile and there is not a timeline (afaict) for its compiling. It 
>>> does not bother you that the 25th proposal considered in the Swift 
>>> evolution process, already once revised, is not fully implemented and may 
>>> never be?
>> 
>> Someone finding a bug/oversight in the compiler behavior does not compel me 
>> to throw out the baby with the bathwater, no.
>> 
>> You're not hearing the argument. No one "accidentally" included this design 
>> as part of SE-0025; it's sentence number one. And no one just "forgot" to 
>> make the code above work; it simply can't be accommodated by the current 
>> mangling scheme. And--what's more--_no one seems to be bothered by it_. If 
>> the first sentence of a proposal can't be implemented, and no one cares (!), 
>> is the proposal fundamentally flawed or is it just some bug?
> 
> The reason nobody cares much is because this is a degenerate case and is not 
> actually how people want to use the feature.  You don’t see people writing 
> identically named fileprivate methods in extensions of a type in different 
> files 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson 
wrote:

>
> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka 
> wrote:
>
>>
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>>
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>>>
>>>
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> om> wrote:
>>>
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:


 So, if four/five access modifiers are too many, which one is carrying
 the least weight? Which one could be removed to simplify the scheme while
 maintaining the most expressiveness? Which one doesn't fulfill even its own
 stated goals? Well, one of the key goals of `private` was to allow members
 to be encapsulated within an extension, hidden even from the type being
 extended (and vice versa for members defined in the type). It says so in
 the first sentence of SE-0025. As seen above in my discussion with Charles
 Srstka, even supporters of `private` disagree with that motivation to begin
 with. The kicker is, _it also doesn't work_. Try, for instance:

 ```
 struct Foo {
   private var bar: Int { return 42 }
 }

 extension Foo {
   private var bar: Int { return 43 }
 }
 ```

 The code above should compile and does not. If I understood correctly
 the explanation from a core team member on this list, it's unclear if it
 can be made to work without changing how mangling works, which I believe
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new
 `private` disagree on one of two key goals stated for new `private`; (b)
 that goal was never accomplished, and making it work is not trivial; (c) no
 one even complained about it, suggesting that it was a low-yield goal in
 the first place.


 Multiple people have already brought up cases in which they are using
 ‘private’. The repeated mention of another, unrelated use case that was
 mentioned in the SE-0025 proposal does not invalidate the real-world use
 cases which have been presented. In fact, it rather makes it appear as if
 the motivation to remove ‘private’ is based on a strange invocation of the
 appeal-to-authority fallacy, rather than an actual improvement to the
 language.

>>>
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully
>>> implemented. And as I said above, IIUC, it cannot be fully implemented
>>> without ripping out a lot of mangling code that is unlikely to be ripped
>>> out before Swift 4. _And there is no evidence that anyone cares about this
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If
>>> this is not sufficient indication that the design of SE-0025 does not fit
>>> with the overall direction of Swift, what would be?
>>>
>>>
>>> Because there are other uses cases for ‘private', *not* involving
>>> extensions, which I *do* care about. The fact that part of the proposal was
>>> badly written (and really, that’s all this is
>>>
>>
>> Huh? The code above *should compile*--that is a primary aim for SE-0025.
>> It does not compile and there is not a timeline (afaict) for its compiling.
>> It does not bother you that the 25th proposal considered in the Swift
>> evolution process, already once revised, is not fully implemented and may
>> never be?
>>
>>
>> Someone finding a bug/oversight in the compiler behavior does not compel
>> me to throw out the baby with the bathwater, no.
>>
>
> You're not hearing the argument. No one "accidentally" included this
> design as part of SE-0025; it's sentence number one. And no one just
> "forgot" to make the code above work; it simply can't be accommodated by
> the current mangling scheme. And--what's more--_no one seems to be bothered
> by it_. If the first sentence of a proposal can't be implemented, and no
> one cares (!), is the proposal fundamentally flawed or is it just some bug?
>
>
> The reason nobody cares much is because this is a degenerate case and is
> not actually how people want to use the feature.  You don’t see people
> writing identically named fileprivate methods in extensions of a type in
> different files either.  The purpose of the feature is not shadowing.  That
> is a side effect.  The purpose is to provide tight compiler-verified
> encapsulation.
>

Isn't supporting the following part and parcel of encapsulation?

```
class Foo {
  private var a: Int { return 42 }
}

class Bar : Foo {
  private var a: Int { return 43 }
  var b: Int { return a }
}

print(Bar().b) // 43
```

Tight compiler-verified encapsulation would, AFAIK, require that the 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:31 PM, Drew Crawford 
wrote:

>
>
>
> On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:
>
> You're not hearing the argument. No one "accidentally" included this
> design as part of SE-0025; it's sentence number one.
>
> To quote this in context:
>
> Scoped access level allows hiding implementation details of a class or a
> class extension at the class/extension level, instead of a file. It is a
> concise expression of the intent that a particular part of a class or
> extension definition is there only to implement a public API for other
> classes or extensions and must not be used directly anywhere outside of the
> scope of the class or the extension.
>
> I can see how an adversarial reading of the first sentence would argue
> that implementation details are not actually hidden by your example (which
> is, for the record, technically correct, the best kind of correct :-).
> However, the second sentence clarifies which kind of implementation details
> we mean to hide – the accidental use of members outside the scope.
>
These are inseparable parts of the whole. It would be absurd if I could not
have a private member in a subclass that happens to be identical to a
private member in a superclass. I can declare an internal member in an
extension to a public type that, in a different module, has an internal
member identically declared. Not being able to do so would be intolerably
broken. This goes to how essential is the encapsulation provided by
subtyping relationships, and how essential is the divide between public and
non-public members.

And this goes to my point: new `private` is enormously complicated, and now
you are trying to convince me that a certain shade of "hidden" is
sufficiently hidden. Proponents arguing for the usefulness of new `private`
show this or that use case that's enabled, but then disown the issues that
arise when the only logical interpretation of the rules leads to scenarios
that are difficult to reason about, use correctly, and (though this not
something that users would be bothered by) even support in the compiler.

> Your example does not involve hiding in that sense, so while it is
> interesting, and a bug, and should be fixed, etc., it does not thwart the
> practicable goal of the proposal.
>
> And no one just "forgot" to make the code above work; it simply can't be
> accommodated by the current mangling scheme.
>
> The Swift mangling scheme changes with some frequency, I know of around 3
> revs offhand and I do not work in that area often.  So holding this up as
> an immovable object is odd.
>
> Things would be different if we declared a stable ABI, but we did not, etc.
>
So that would be at least three revs that can't accommodate this feature. A
stable ABI may not be 4.0, but it isn't terribly far off. The window is
closing to fix the implementation, and it's not obvious that there is a
good solution.

> And--what's more--_no one seems to be bothered by it_.
>
> I volunteer to be bothered by it.  Where’s my cookie?
>
 . More if you volunteer to be sufficiently bothered to fix it.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka  > wrote:
> 
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu >> > wrote:
>> 
>>> 
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 So, if four/five access modifiers are too many, which one is carrying the 
 least weight? Which one could be removed to simplify the scheme while 
 maintaining the most expressiveness? Which one doesn't fulfill even its 
 own stated goals? Well, one of the key goals of `private` was to allow 
 members to be encapsulated within an extension, hidden even from the type 
 being extended (and vice versa for members defined in the type). It says 
 so in the first sentence of SE-0025. As seen above in my discussion with 
 Charles Srstka, even supporters of `private` disagree with that motivation 
 to begin with. The kicker is, _it also doesn't work_. Try, for instance:
 
 ```
 struct Foo {
   private var bar: Int { return 42 }
 }
 
 extension Foo {
   private var bar: Int { return 43 }
 }
 ```
 
 The code above should compile and does not. If I understood correctly the 
 explanation from a core team member on this list, it's unclear if it can 
 be made to work without changing how mangling works, which I believe 
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
 `private` disagree on one of two key goals stated for new `private`; (b) 
 that goal was never accomplished, and making it work is not trivial; (c) 
 no one even complained about it, suggesting that it was a low-yield goal 
 in the first place.
>>> 
>>> Multiple people have already brought up cases in which they are using 
>>> ‘private’. The repeated mention of another, unrelated use case that was 
>>> mentioned in the SE-0025 proposal does not invalidate the real-world use 
>>> cases which have been presented. In fact, it rather makes it appear as if 
>>> the motivation to remove ‘private’ is based on a strange invocation of the 
>>> appeal-to-authority fallacy, rather than an actual improvement to the 
>>> language.
>>> 
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
>>> implemented. And as I said above, IIUC, it cannot be fully implemented 
>>> without ripping out a lot of mangling code that is unlikely to be ripped 
>>> out before Swift 4. _And there is no evidence that anyone cares about this 
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If 
>>> this is not sufficient indication that the design of SE-0025 does not fit 
>>> with the overall direction of Swift, what would be?
>> 
>> Because there are other uses cases for ‘private', *not* involving 
>> extensions, which I *do* care about. The fact that part of the proposal was 
>> badly written (and really, that’s all this is
>> 
>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>> does not compile and there is not a timeline (afaict) for its compiling. It 
>> does not bother you that the 25th proposal considered in the Swift evolution 
>> process, already once revised, is not fully implemented and may never be?
> 
> Someone finding a bug/oversight in the compiler behavior does not compel me 
> to throw out the baby with the bathwater, no.
> 
> You're not hearing the argument. No one "accidentally" included this design 
> as part of SE-0025; it's sentence number one.

Or not. Here’s the actual text of the introductory paragraph:

"Scoped access level allows hiding implementation details of a class or a class 
extension at the class/extension level, instead of a file. It is a concise 
expression of the intent that a particular part of a class or extension 
definition is there only to implement a public API for other classes or 
extensions and must not be used directly anywhere outside of the scope of the 
class or the extension.”

So here we have “class or extension”, or some variant thereof, five separate 
times. It honestly reads like it originally just said “class”, and the author 
systematically went through it and added “or extension” to each of them to make 
sure his/her bases were covered. And didn’t quite succeed; the wording doesn’t 
account for value types.

And anyway, I’m not sure how you even get “extensions should be able to shadow 
private members” as Priority Number 

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

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka  > wrote:
> 
>> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > > wrote:
>> 
>> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu >> > wrote:
>> 
>>> 
>>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >> > wrote:
 On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 So, if four/five access modifiers are too many, which one is carrying the 
 least weight? Which one could be removed to simplify the scheme while 
 maintaining the most expressiveness? Which one doesn't fulfill even its 
 own stated goals? Well, one of the key goals of `private` was to allow 
 members to be encapsulated within an extension, hidden even from the type 
 being extended (and vice versa for members defined in the type). It says 
 so in the first sentence of SE-0025. As seen above in my discussion with 
 Charles Srstka, even supporters of `private` disagree with that motivation 
 to begin with. The kicker is, _it also doesn't work_. Try, for instance:
 
 ```
 struct Foo {
   private var bar: Int { return 42 }
 }
 
 extension Foo {
   private var bar: Int { return 43 }
 }
 ```
 
 The code above should compile and does not. If I understood correctly the 
 explanation from a core team member on this list, it's unclear if it can 
 be made to work without changing how mangling works, which I believe 
 impacts ABI and is not trivial at all. Thus, (a) even proponents of new 
 `private` disagree on one of two key goals stated for new `private`; (b) 
 that goal was never accomplished, and making it work is not trivial; (c) 
 no one even complained about it, suggesting that it was a low-yield goal 
 in the first place.
>>> 
>>> Multiple people have already brought up cases in which they are using 
>>> ‘private’. The repeated mention of another, unrelated use case that was 
>>> mentioned in the SE-0025 proposal does not invalidate the real-world use 
>>> cases which have been presented. In fact, it rather makes it appear as if 
>>> the motivation to remove ‘private’ is based on a strange invocation of the 
>>> appeal-to-authority fallacy, rather than an actual improvement to the 
>>> language.
>>> 
>>> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
>>> implemented. And as I said above, IIUC, it cannot be fully implemented 
>>> without ripping out a lot of mangling code that is unlikely to be ripped 
>>> out before Swift 4. _And there is no evidence that anyone cares about this 
>>> flaw; in fact, you are saying as much, that you do not care at all!_ If 
>>> this is not sufficient indication that the design of SE-0025 does not fit 
>>> with the overall direction of Swift, what would be?
>> 
>> Because there are other uses cases for ‘private', *not* involving 
>> extensions, which I *do* care about. The fact that part of the proposal was 
>> badly written (and really, that’s all this is
>> 
>> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
>> does not compile and there is not a timeline (afaict) for its compiling. It 
>> does not bother you that the 25th proposal considered in the Swift evolution 
>> process, already once revised, is not fully implemented and may never be?
> 
> Someone finding a bug/oversight in the compiler behavior does not compel me 
> to throw out the baby with the bathwater, no.
> 
> You're not hearing the argument. No one "accidentally" included this design 
> as part of SE-0025; it's sentence number one. And no one just "forgot" to 
> make the code above work; it simply can't be accommodated by the current 
> mangling scheme. And--what's more--_no one seems to be bothered by it_. If 
> the first sentence of a proposal can't be implemented, and no one cares (!), 
> is the proposal fundamentally flawed or is it just some bug?

The reason nobody cares much is because this is a degenerate case and is not 
actually how people want to use the feature.  You don’t see people writing 
identically named fileprivate methods in extensions of a type in different 
files either.  The purpose of the feature is not shadowing.  That is a side 
effect.  The purpose is to provide tight compiler-verified encapsulation.  
Nothing more, nothing less.

>> —it uses “class or extension” as a synonym for “any type declaration" when 
>> really, it makes just as much sense for structs to have private members as 
>> 

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

[Drew Crawford via swift-evolution]

On March 21, 2017 at 9:18:00 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote:

You're not hearing the argument. No one "accidentally" included this design as 
part of SE-0025; it's sentence number one. 
To quote this in context:

Scoped access level allows hiding implementation details of a class or a class 
extension at the class/extension level, instead of a file. It is a concise 
expression of the intent that a particular part of a class or extension 
definition is there only to implement a public API for other classes or 
extensions and must not be used directly anywhere outside of the scope of the 
class or the extension.

I can see how an adversarial reading of the first sentence would argue that 
implementation details are not actually hidden by your example (which is, for 
the record, technically correct, the best kind of correct :-).  However, the 
second sentence clarifies which kind of implementation details we mean to hide 
– the accidental use of members outside the scope.

Your example does not involve hiding in that sense, so while it is interesting, 
and a bug, and should be fixed, etc., it does not thwart the practicable goal 
of the proposal.

And no one just "forgot" to make the code above work; it simply can't be 
accommodated by the current mangling scheme. 
The Swift mangling scheme changes with some frequency, I know of around 3 revs 
offhand and I do not work in that area often.  So holding this up as an 
immovable object is odd.

Things would be different if we declared a stable ABI, but we did not, etc.

And--what's more--_no one seems to be bothered by it_.
I volunteer to be bothered by it.  Where’s my cookie?___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 8:31 PM, Matthew Johnson 
wrote:

>
>
> Sent from my iPad
>
> On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford 
> wrote:
>
>> I am confused by this response. An argument in _support_ of new `private`
>> was that it is more in line with expectations of users coming from other
>> languages. In other some cases, such an argument might have its place.
>> However, as others have pointed out on this list, those other languages
>> don't have facilities like Swift's extensions, and therefore it was not a
>> very strong argument for new `private` to say that it better aligns with
>> user expectations coming from other languages.
>>
>> The underlying issue here (which I have now identified, thanks!) is what
>> motivates the use of extensions.  That question predates proposals, but the
>> Swift book provides the following motivation, which I have numbered for
>> ease of reference:
>>
>> 1. Extensions add new functionality to an existing class, structure,
>> enumeration, or protocol type.
>>
>> 2. This includes the ability to extend types for which you do not have
>> access to the original source code (known as retroactive modeling).
>>
>> 3. Extensions are similar to categories in Objective-C.
>>
>> It seems to me this motivation contemplates use “at some distance”, that
>> is we intend to create some semantically meaningful separation between the
>> declaration and the extension(s).  If we did not we could use MARK or some
>> other comment-based scheme to organize our class.
>>
>> 2 is explicitly at great distance, so we know the distance motivation is
>> well within scope.  1 refers to “an existing” type which implies a certain
>> level of functionality in the unextended type, and not merely a partial
>> implementation in the unextended type.  The record on 3 is more mixed (ObjC
>> programmers do occasionally use categories “closely-held” to group a few
>> methods together).  However ObjC also has the “distance” tradition:
>> categories cannot introduce new storage even when this is technically
>> trivial (within the same compilation unit for example), and this tradition
>> was continued under Swift with the new ABI.
>>
>> What I am suggesting is that the primary design purpose of an extension
>> is to create semantic distance between a declaration and the functionality
>> being added.
>>
>
> I'm not sure it is necessary for extensions to have a "primary design
> purpose." They serve many purposes. One use I have for them is as follows:
>
> ```
> struct A {
>   // Stuff here constitutes the "raison d'etre" for A.
> }
>
> extension A : B {
>   // In the course of implementing `A`, I have discovered that
>   // `A` can fulfill the semantic guarantees of `B`, and in fact
>   // fulfills most of them already.
>   //
>   // So, I conform to B, as in so doing there are some practical
>   // advantages, such as gaining some default implementations.
>   //
>   // But, to conform, I may need to implement some methods
>   // not really essential for a functional `A`, but required nonetheless
>   // to conform to `B`.
>   //
>   // I implement them here in an extension; in so doing, I express
>   // the idea that I have, after implementing `A`, discovered its
>   // conformance to `B`, and I am here supplying the remaining
>   // implementations necessary for that conformance.
>   //
>   // That is, if `B` did not exist, neither would these functions here.
>   // But there may be some requirements of `B` that would be
>   // implemented in `A` whether or not `B` exists.
>   // Those are implemented above, in `struct A { ... }`.
> }
> ```
>
> I find this to be an eloquent way to separate concerns. It is a common
> pattern encouraged by code I admire written by others more skilled than me
> in Swift.
>
> A mechanism to hide variables from extensions is something that *furthers*
>> this design goal of extensions, rather than contradicts it.
>>
>
> This, I suppose, is an argument for you to take up with Charles.
>
>
>> I understand that some people use extensions as sort of an imitation
>> “partial class” but they simply aren’t (no storage) and we should introduce
>> a new feature if we want to have them.
>>
>> A core team member (I'm blanking on who) has pointed out that, in the
>> end, the only necessary access modifiers are public and not public (spelled
>> "internal" in Swift).
>>
>>
>> It is not clear to me how this squares with the decision in SE-0025 that
>> other access modifiers were necessary.  Can you clarify?
>>
>
> Why do you think SE-0025 decided that other access modifiers are
> necessary? It merely decided that having four was deemed, on balance,
> superior to having three. But the minimum number of access modifiers is, by
> definition, two. In the case of Swift those essentially have to be at the
> module boundary. Anything more finely diced 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 9:15 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
>
> On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution (
> swift-evolution@swift.org) wrote:
>
> Swift should only impose a preference when it's important to the speed,
> functionality, and safety of the language. I have yet to be convinced that
> there's a benefit to a scoped access level that fits anywhere in there.
>
> SE-0025 addresses these *specific* points.
>
> speed & safety:
>
> > Also, there is a greater danger of using private APIs if they do
> something similar to public APIs but are somehow more optimized (because
> they make additional assumptions about the internal state).
>
> functionality:
>
> > It forces a one class per file structure, which is very limiting.
> Putting related APIs and/or related implementations in the same file helps
> ensure consistency and reduces the time to find a particular API or
> implementation. This does not mean that the classes in the same file need
> to share otherwise hidden APIs, but there is no way to express such
> sharability with the current access levels.
>
>
>
>
> I have spent entire weeks of class trying to extoll the benefits, so
> breathlessly shared on these mailing lists, of how beautiful it is to have
> a scoped access level. I have yet to succeed.
>
> Perhaps this suggests scoped access modifiers are more comparable to e.g.
> “owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107.
> Those features are breathtakingly difficult to teach, with design documents
> in the dozens of pages that are so dense I do not understand them.
>
> However, they solve hairy problems down in the dungeon somewhere, and most
> programmers do not actually need to know them to write their code.
>
> I don’t think scoped is quite to that level, but even if it were: if you
> like your visibility modifiers you can keep them!  There is no law that
> says you must use all the modifiers,
>
No, but you must understand what all of them mean to reason about code. You
can read and write a lot of useful Swift without understanding raw
pointers. You cannot reason about Swift code very well if you do not
understand access modifiers, especially `private`. If you're arguing that
new `private` is necessary to solve "hairy problems down in the dungeon
somewhere," it should certainly not be the so-called "soft" default that
comes with being named `private`. That is the diametrical opposite of how
it was pitched in SE-0025, where it's expected to be the overwhelmingly
most common choice.

And again, interoperability with C is a tentpole feature of Swift, so the
balance is different. Swift makes no such promises about encapsulation
within a module; in fact, IIUC it's a non-goal. So the balance between
power and teachability is distinctly different.

> and the availability of a feature does not “impose on all of us the
> personal code style preferences” of anyone.  Removing a feature does, and
> that’s the present proposal.
>
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka 
wrote:

>
> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
>
> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka 
>  wrote:
>
>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>>
>>
>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > > wrote:
>>
>>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>>
>>> So, if four/five access modifiers are too many, which one is carrying
>>> the least weight? Which one could be removed to simplify the scheme while
>>> maintaining the most expressiveness? Which one doesn't fulfill even its own
>>> stated goals? Well, one of the key goals of `private` was to allow members
>>> to be encapsulated within an extension, hidden even from the type being
>>> extended (and vice versa for members defined in the type). It says so in
>>> the first sentence of SE-0025. As seen above in my discussion with Charles
>>> Srstka, even supporters of `private` disagree with that motivation to begin
>>> with. The kicker is, _it also doesn't work_. Try, for instance:
>>>
>>> ```
>>> struct Foo {
>>>   private var bar: Int { return 42 }
>>> }
>>>
>>> extension Foo {
>>>   private var bar: Int { return 43 }
>>> }
>>> ```
>>>
>>> The code above should compile and does not. If I understood correctly
>>> the explanation from a core team member on this list, it's unclear if it
>>> can be made to work without changing how mangling works, which I believe
>>> impacts ABI and is not trivial at all. Thus, (a) even proponents of new
>>> `private` disagree on one of two key goals stated for new `private`; (b)
>>> that goal was never accomplished, and making it work is not trivial; (c) no
>>> one even complained about it, suggesting that it was a low-yield goal in
>>> the first place.
>>>
>>>
>>> Multiple people have already brought up cases in which they are using
>>> ‘private’. The repeated mention of another, unrelated use case that was
>>> mentioned in the SE-0025 proposal does not invalidate the real-world use
>>> cases which have been presented. In fact, it rather makes it appear as if
>>> the motivation to remove ‘private’ is based on a strange invocation of the
>>> appeal-to-authority fallacy, rather than an actual improvement to the
>>> language.
>>>
>>
>> I'm not sure how to respond to this. SE-0025, as designed, is not fully
>> implemented. And as I said above, IIUC, it cannot be fully implemented
>> without ripping out a lot of mangling code that is unlikely to be ripped
>> out before Swift 4. _And there is no evidence that anyone cares about this
>> flaw; in fact, you are saying as much, that you do not care at all!_ If
>> this is not sufficient indication that the design of SE-0025 does not fit
>> with the overall direction of Swift, what would be?
>>
>>
>> Because there are other uses cases for ‘private', *not* involving
>> extensions, which I *do* care about. The fact that part of the proposal was
>> badly written (and really, that’s all this is
>>
>
> Huh? The code above *should compile*--that is a primary aim for SE-0025.
> It does not compile and there is not a timeline (afaict) for its compiling.
> It does not bother you that the 25th proposal considered in the Swift
> evolution process, already once revised, is not fully implemented and may
> never be?
>
>
> Someone finding a bug/oversight in the compiler behavior does not compel
> me to throw out the baby with the bathwater, no.
>

You're not hearing the argument. No one "accidentally" included this design
as part of SE-0025; it's sentence number one. And no one just "forgot" to
make the code above work; it simply can't be accommodated by the current
mangling scheme. And--what's more--_no one seems to be bothered by it_. If
the first sentence of a proposal can't be implemented, and no one cares
(!), is the proposal fundamentally flawed or is it just some bug?

> —it uses “class or extension” as a synonym for “any type declaration" when
>> really, it makes just as much sense for structs to have private members as
>> classes. Stuff happens!) does not invalidate the other use cases. And yes,
>> I’m aware that my coding style may differ from other people, who may use
>> the language in a different way. We shouldn’t break *their* use cases,
>> either.
>>
>
> We shouldn't break their use cases _without good reason_, but we shouldn't
> hesitate to break their use cases if (a) there is an extremely justifiable
> reason for it; and (b) the migration path is straightforward; and
> (preferably) also (c) the breakage is relatively uncommon. I happen to
> think those criteria are met for the reasons I've outlined extensively
> above, and you may certainly quibble with that conclusion
>
>
> We’re simply going to have to disagree here.
>
> Charles
>
>
___
swift-evolution mailing list

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

[Drew Crawford via swift-evolution]

On March 21, 2017 at 7:45:22 PM, Zach Waldowski via swift-evolution 
(swift-evolution@swift.org) wrote:

Swift should only impose a preference when it's important to the speed, 
functionality, and safety of the language. I have yet to be convinced that 
there's a benefit to a scoped access level that fits anywhere in there.
SE-0025 addresses these *specific* points.

speed & safety:

> Also, there is a greater danger of using private APIs if they do something 
> similar to public APIs but are somehow more optimized (because they make 
> additional assumptions about the internal state).
functionality:

> It forces a one class per file structure, which is very limiting. Putting 
> related APIs and/or related implementations in the same file helps ensure 
> consistency and reduces the time to find a particular API or implementation. 
> This does not mean that the classes in the same file need to share otherwise 
> hidden APIs, but there is no way to express such sharability with the current 
> access levels.



I have spent entire weeks of class trying to extoll the benefits, so 
breathlessly shared on these mailing lists, of how beautiful it is to have a 
scoped access level. I have yet to succeed.
Perhaps this suggests scoped access modifiers are more comparable to e.g. 
“owned” in the Memory Management Manifesto or UnsafeRawPointer/SE-0107.  Those 
features are breathtakingly difficult to teach, with design documents in the 
dozens of pages that are so dense I do not understand them.

However, they solve hairy problems down in the dungeon somewhere, and most 
programmers do not actually need to know them to write their code.

I don’t think scoped is quite to that level, but even if it were: if you like 
your visibility modifiers you can keep them!  There is no law that says you 
must use all the modifiers, and the availability of a feature does not “impose 
on all of us the personal code style preferences” of anyone.  Removing a 
feature does, and that’s the present proposal.

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

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

[Rob Mayoff via swift-evolution]

On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> A core team member (I'm blanking on who) has pointed out that, in the end,
> the only necessary access modifiers are public and not public (spelled
> "internal" in Swift).
>
>
> It is not clear to me how this squares with the decision in SE-0025 that
> other access modifiers were necessary.  Can you clarify?
>

I believe the reference is to this comment by Slava Pestov on 2017-02-16:

While we’re bikeshedding, I’m going to add my two cents. Hold on to your
> hat
> because this might be controversial here.
>
> I think both ‘private’ and ‘fileprivate’ are unnecessary complications
> that
> only serve to clutter the language.
>


It would make a lot more sense to just have internal and public only. No
> private, no fileprivate, no lineprivate, no protected. It’s all silly.


https://www.mail-archive.com/swift-evolution@swift.org/msg21766.html
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > > wrote:
> 
>> 
>> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > > wrote:
>>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
>>> So, if four/five access modifiers are too many, which one is carrying the 
>>> least weight? Which one could be removed to simplify the scheme while 
>>> maintaining the most expressiveness? Which one doesn't fulfill even its own 
>>> stated goals? Well, one of the key goals of `private` was to allow members 
>>> to be encapsulated within an extension, hidden even from the type being 
>>> extended (and vice versa for members defined in the type). It says so in 
>>> the first sentence of SE-0025. As seen above in my discussion with Charles 
>>> Srstka, even supporters of `private` disagree with that motivation to begin 
>>> with. The kicker is, _it also doesn't work_. Try, for instance:
>>> 
>>> ```
>>> struct Foo {
>>>   private var bar: Int { return 42 }
>>> }
>>> 
>>> extension Foo {
>>>   private var bar: Int { return 43 }
>>> }
>>> ```
>>> 
>>> The code above should compile and does not. If I understood correctly the 
>>> explanation from a core team member on this list, it's unclear if it can be 
>>> made to work without changing how mangling works, which I believe impacts 
>>> ABI and is not trivial at all. Thus, (a) even proponents of new `private` 
>>> disagree on one of two key goals stated for new `private`; (b) that goal 
>>> was never accomplished, and making it work is not trivial; (c) no one even 
>>> complained about it, suggesting that it was a low-yield goal in the first 
>>> place.
>> 
>> Multiple people have already brought up cases in which they are using 
>> ‘private’. The repeated mention of another, unrelated use case that was 
>> mentioned in the SE-0025 proposal does not invalidate the real-world use 
>> cases which have been presented. In fact, it rather makes it appear as if 
>> the motivation to remove ‘private’ is based on a strange invocation of the 
>> appeal-to-authority fallacy, rather than an actual improvement to the 
>> language.
>> 
>> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
>> implemented. And as I said above, IIUC, it cannot be fully implemented 
>> without ripping out a lot of mangling code that is unlikely to be ripped out 
>> before Swift 4. _And there is no evidence that anyone cares about this flaw; 
>> in fact, you are saying as much, that you do not care at all!_ If this is 
>> not sufficient indication that the design of SE-0025 does not fit with the 
>> overall direction of Swift, what would be?
> 
> Because there are other uses cases for ‘private', *not* involving extensions, 
> which I *do* care about. The fact that part of the proposal was badly written 
> (and really, that’s all this is
> 
> Huh? The code above *should compile*--that is a primary aim for SE-0025. It 
> does not compile and there is not a timeline (afaict) for its compiling. It 
> does not bother you that the 25th proposal considered in the Swift evolution 
> process, already once revised, is not fully implemented and may never be?

Someone finding a bug/oversight in the compiler behavior does not compel me to 
throw out the baby with the bathwater, no.

> —it uses “class or extension” as a synonym for “any type declaration" when 
> really, it makes just as much sense for structs to have private members as 
> classes. Stuff happens!) does not invalidate the other use cases. And yes, 
> I’m aware that my coding style may differ from other people, who may use the 
> language in a different way. We shouldn’t break *their* use cases, either.
> 
> We shouldn't break their use cases _without good reason_, but we shouldn't 
> hesitate to break their use cases if (a) there is an extremely justifiable 
> reason for it; and (b) the migration path is straightforward; and 
> (preferably) also (c) the breakage is relatively uncommon. I happen to think 
> those criteria are met for the reasons I've outlined extensively above, and 
> you may certainly quibble with that conclusion

We’re simply going to have to disagree here.

Charles

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

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford  
>> wrote:
 I am confused by this response. An argument in _support_ of new `private` 
 was that it is more in line with expectations of users coming from other 
 languages. In other some cases, such an argument might have its place. 
 However, as others have pointed out on this list, those other languages 
 don't have facilities like Swift's extensions, and therefore it was not a 
 very strong argument for new `private` to say that it better aligns with 
 user expectations coming from other languages.
>>> 
>>> The underlying issue here (which I have now identified, thanks!) is what 
>>> motivates the use of extensions.  That question predates proposals, but the 
>>> Swift book provides the following motivation, which I have numbered for 
>>> ease of reference:
>>> 
>>> 1. Extensions add new functionality to an existing class, structure, 
>>> enumeration, or protocol type. 
>>> 2. This includes the ability to extend types for which you do not have 
>>> access to the original source code (known as retroactive modeling). 
>>> 
>>> 3. Extensions are similar to categories in Objective-C.
>>> 
>> 
>> It seems to me this motivation contemplates use “at some distance”, that is 
>> we intend to create some semantically meaningful separation between the 
>> declaration and the extension(s).  If we did not we could use MARK or some 
>> other comment-based scheme to organize our class.
>> 
>> 2 is explicitly at great distance, so we know the distance motivation is 
>> well within scope.  1 refers to “an existing” type which implies a certain 
>> level of functionality in the unextended type, and not merely a partial 
>> implementation in the unextended type.  The record on 3 is more mixed (ObjC 
>> programmers do occasionally use categories “closely-held” to group a few 
>> methods together).  However ObjC also has the “distance” tradition: 
>> categories cannot introduce new storage even when this is technically 
>> trivial (within the same compilation unit for example), and this tradition 
>> was continued under Swift with the new ABI.
>> 
>> What I am suggesting is that the primary design purpose of an extension is 
>> to create semantic distance between a declaration and the functionality 
>> being added.
> 
> I'm not sure it is necessary for extensions to have a "primary design 
> purpose." They serve many purposes. One use I have for them is as follows:
> 
> ```
> struct A {
>   // Stuff here constitutes the "raison d'etre" for A.
> }
> 
> extension A : B {
>   // In the course of implementing `A`, I have discovered that
>   // `A` can fulfill the semantic guarantees of `B`, and in fact
>   // fulfills most of them already.
>   //
>   // So, I conform to B, as in so doing there are some practical
>   // advantages, such as gaining some default implementations.
>   //
>   // But, to conform, I may need to implement some methods
>   // not really essential for a functional `A`, but required nonetheless
>   // to conform to `B`.
>   //
>   // I implement them here in an extension; in so doing, I express
>   // the idea that I have, after implementing `A`, discovered its
>   // conformance to `B`, and I am here supplying the remaining
>   // implementations necessary for that conformance.
>   //
>   // That is, if `B` did not exist, neither would these functions here.
>   // But there may be some requirements of `B` that would be
>   // implemented in `A` whether or not `B` exists.
>   // Those are implemented above, in `struct A { ... }`.
> }
> ```
> 
> I find this to be an eloquent way to separate concerns. It is a common 
> pattern encouraged by code I admire written by others more skilled than me in 
> Swift.
> 
>> A mechanism to hide variables from extensions is something that *furthers* 
>> this design goal of extensions, rather than contradicts it.
> 
> This, I suppose, is an argument for you to take up with Charles.
>  
>> I understand that some people use extensions as sort of an imitation 
>> “partial class” but they simply aren’t (no storage) and we should introduce 
>> a new feature if we want to have them.
>> 
>>> A core team member (I'm blanking on who) has pointed out that, in the end, 
>>> the only necessary access modifiers are public and not public (spelled 
>>> "internal" in Swift).
>> 
>> 
>> It is not clear to me how this squares with the decision in SE-0025 that 
>> other access modifiers were necessary.  Can you clarify?
> 
> Why do you think SE-0025 decided that other access modifiers are necessary? 
> It merely decided that having four was deemed, on balance, superior to having 
> three. But the minimum number of access modifiers is, by definition, two. In 
> the case of Swift those essentially have to be at the module boundary. 
> Anything more finely diced than 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
>
>
> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka 
>  wrote:
>
>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> So, if four/five access modifiers are too many, which one is carrying the
>> least weight? Which one could be removed to simplify the scheme while
>> maintaining the most expressiveness? Which one doesn't fulfill even its own
>> stated goals? Well, one of the key goals of `private` was to allow members
>> to be encapsulated within an extension, hidden even from the type being
>> extended (and vice versa for members defined in the type). It says so in
>> the first sentence of SE-0025. As seen above in my discussion with Charles
>> Srstka, even supporters of `private` disagree with that motivation to begin
>> with. The kicker is, _it also doesn't work_. Try, for instance:
>>
>> ```
>> struct Foo {
>>   private var bar: Int { return 42 }
>> }
>>
>> extension Foo {
>>   private var bar: Int { return 43 }
>> }
>> ```
>>
>> The code above should compile and does not. If I understood correctly the
>> explanation from a core team member on this list, it's unclear if it can be
>> made to work without changing how mangling works, which I believe impacts
>> ABI and is not trivial at all. Thus, (a) even proponents of new `private`
>> disagree on one of two key goals stated for new `private`; (b) that goal
>> was never accomplished, and making it work is not trivial; (c) no one even
>> complained about it, suggesting that it was a low-yield goal in the first
>> place.
>>
>>
>> Multiple people have already brought up cases in which they are using
>> ‘private’. The repeated mention of another, unrelated use case that was
>> mentioned in the SE-0025 proposal does not invalidate the real-world use
>> cases which have been presented. In fact, it rather makes it appear as if
>> the motivation to remove ‘private’ is based on a strange invocation of the
>> appeal-to-authority fallacy, rather than an actual improvement to the
>> language.
>>
>
> I'm not sure how to respond to this. SE-0025, as designed, is not fully
> implemented. And as I said above, IIUC, it cannot be fully implemented
> without ripping out a lot of mangling code that is unlikely to be ripped
> out before Swift 4. _And there is no evidence that anyone cares about this
> flaw; in fact, you are saying as much, that you do not care at all!_ If
> this is not sufficient indication that the design of SE-0025 does not fit
> with the overall direction of Swift, what would be?
>
>
> Because there are other uses cases for ‘private', *not* involving
> extensions, which I *do* care about. The fact that part of the proposal was
> badly written (and really, that’s all this is
>

Huh? The code above *should compile*--that is a primary aim for SE-0025. It
does not compile and there is not a timeline (afaict) for its compiling. It
does not bother you that the 25th proposal considered in the Swift
evolution process, already once revised, is not fully implemented and may
never be?

—it uses “class or extension” as a synonym for “any type declaration" when
> really, it makes just as much sense for structs to have private members as
> classes. Stuff happens!) does not invalidate the other use cases. And yes,
> I’m aware that my coding style may differ from other people, who may use
> the language in a different way. We shouldn’t break *their* use cases,
> either.
>

We shouldn't break their use cases _without good reason_, but we shouldn't
hesitate to break their use cases if (a) there is an extremely justifiable
reason for it; and (b) the migration path is straightforward; and
(preferably) also (c) the breakage is relatively uncommon. I happen to
think those criteria are met for the reasons I've outlined extensively
above, and you may certainly quibble with that conclusion--but saying that
we shouldn't break anyone's use case, period, is not at all reasonable.

Many people used to argue against early returns as being tantamount to
>> littering one’s code with GOTO statements willy-nilly, instead advocating
>> for assigning to a return variable which would then be returned in the last
>> line of the function. Swift explicitly rejects this view, offering
>> constructs such as the guard statement and the error-handling mechanism
>> which specifically encourage early returns. However, I don’t see people
>> using the non-acceptance of this particular argument against GOTOs as an
>> argument for eliminating all structured flow control from the language.
>>
>
> I don't follow. Which people have argued against structured control flow
> in Swift?
>
>
> No one has. That’s the point!
>
> Charles
>
>
___
swift-evolution mailing list
swift-evolution@swift.org

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

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu  wrote:
> 
> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka  > wrote:
>> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> So, if four/five access modifiers are too many, which one is carrying the 
>> least weight? Which one could be removed to simplify the scheme while 
>> maintaining the most expressiveness? Which one doesn't fulfill even its own 
>> stated goals? Well, one of the key goals of `private` was to allow members 
>> to be encapsulated within an extension, hidden even from the type being 
>> extended (and vice versa for members defined in the type). It says so in the 
>> first sentence of SE-0025. As seen above in my discussion with Charles 
>> Srstka, even supporters of `private` disagree with that motivation to begin 
>> with. The kicker is, _it also doesn't work_. Try, for instance:
>> 
>> ```
>> struct Foo {
>>   private var bar: Int { return 42 }
>> }
>> 
>> extension Foo {
>>   private var bar: Int { return 43 }
>> }
>> ```
>> 
>> The code above should compile and does not. If I understood correctly the 
>> explanation from a core team member on this list, it's unclear if it can be 
>> made to work without changing how mangling works, which I believe impacts 
>> ABI and is not trivial at all. Thus, (a) even proponents of new `private` 
>> disagree on one of two key goals stated for new `private`; (b) that goal was 
>> never accomplished, and making it work is not trivial; (c) no one even 
>> complained about it, suggesting that it was a low-yield goal in the first 
>> place.
> 
> Multiple people have already brought up cases in which they are using 
> ‘private’. The repeated mention of another, unrelated use case that was 
> mentioned in the SE-0025 proposal does not invalidate the real-world use 
> cases which have been presented. In fact, it rather makes it appear as if the 
> motivation to remove ‘private’ is based on a strange invocation of the 
> appeal-to-authority fallacy, rather than an actual improvement to the 
> language.
> 
> I'm not sure how to respond to this. SE-0025, as designed, is not fully 
> implemented. And as I said above, IIUC, it cannot be fully implemented 
> without ripping out a lot of mangling code that is unlikely to be ripped out 
> before Swift 4. _And there is no evidence that anyone cares about this flaw; 
> in fact, you are saying as much, that you do not care at all!_ If this is not 
> sufficient indication that the design of SE-0025 does not fit with the 
> overall direction of Swift, what would be?

Because there are other uses cases for ‘private', *not* involving extensions, 
which I *do* care about. The fact that part of the proposal was badly written 
(and really, that’s all this is—it uses “class or extension” as a synonym for 
“any type declaration" when really, it makes just as much sense for structs to 
have private members as classes. Stuff happens!) does not invalidate the other 
use cases. And yes, I’m aware that my coding style may differ from other 
people, who may use the language in a different way. We shouldn’t break *their* 
use cases, either.

> Many people used to argue against early returns as being tantamount to 
> littering one’s code with GOTO statements willy-nilly, instead advocating for 
> assigning to a return variable which would then be returned in the last line 
> of the function. Swift explicitly rejects this view, offering constructs such 
> as the guard statement and the error-handling mechanism which specifically 
> encourage early returns. However, I don’t see people using the non-acceptance 
> of this particular argument against GOTOs as an argument for eliminating all 
> structured flow control from the language.
> 
> I don't follow. Which people have argued against structured control flow in 
> Swift?

No one has. That’s the point!

Charles

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

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka 
wrote:

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> So, if four/five access modifiers are too many, which one is carrying the
> least weight? Which one could be removed to simplify the scheme while
> maintaining the most expressiveness? Which one doesn't fulfill even its own
> stated goals? Well, one of the key goals of `private` was to allow members
> to be encapsulated within an extension, hidden even from the type being
> extended (and vice versa for members defined in the type). It says so in
> the first sentence of SE-0025. As seen above in my discussion with Charles
> Srstka, even supporters of `private` disagree with that motivation to begin
> with. The kicker is, _it also doesn't work_. Try, for instance:
>
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
>
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
>
> The code above should compile and does not. If I understood correctly the
> explanation from a core team member on this list, it's unclear if it can be
> made to work without changing how mangling works, which I believe impacts
> ABI and is not trivial at all. Thus, (a) even proponents of new `private`
> disagree on one of two key goals stated for new `private`; (b) that goal
> was never accomplished, and making it work is not trivial; (c) no one even
> complained about it, suggesting that it was a low-yield goal in the first
> place.
>
>
> Multiple people have already brought up cases in which they are using
> ‘private’. The repeated mention of another, unrelated use case that was
> mentioned in the SE-0025 proposal does not invalidate the real-world use
> cases which have been presented. In fact, it rather makes it appear as if
> the motivation to remove ‘private’ is based on a strange invocation of the
> appeal-to-authority fallacy, rather than an actual improvement to the
> language.
>

I'm not sure how to respond to this. SE-0025, as designed, is not fully
implemented. And as I said above, IIUC, it cannot be fully implemented
without ripping out a lot of mangling code that is unlikely to be ripped
out before Swift 4. _And there is no evidence that anyone cares about this
flaw; in fact, you are saying as much, that you do not care at all!_ If
this is not sufficient indication that the design of SE-0025 does not fit
with the overall direction of Swift, what would be?


Many people used to argue against early returns as being tantamount to
> littering one’s code with GOTO statements willy-nilly, instead advocating
> for assigning to a return variable which would then be returned in the last
> line of the function. Swift explicitly rejects this view, offering
> constructs such as the guard statement and the error-handling mechanism
> which specifically encourage early returns. However, I don’t see people
> using the non-acceptance of this particular argument against GOTOs as an
> argument for eliminating all structured flow control from the language.
>

I don't follow. Which people have argued against structured control flow in
Swift? And what does that have to do with rolling back a partially
implemented proposal?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Waldowski via swift-evolution]

On Tue, Mar 21, 2017, at 07:44 PM, Drew Crawford via swift-evolution wrote:
>> When new `private` and `fileprivate` were shipped, there were
>> numerous questions asked by users on forums such as Stack Overflow
> 

> And before they were shipped, there were people asking for a scoped
> modifier.  And when we change them again, what questions will that
> generate?  So I don’t see what we are accomplishing with this line of
> inquiry.
> 

>> You see the new access modifiers described, for example, as something
>> that "take[s] some getting used to." Rather damning as a euphemism,
>> don't you think?
> Not at all.  We could describe strong typing, or optionals, enums,
> pattern matching, etc., in this way.  ARC in particular is “difficult
> to teach” but we should not get rid of it, it solves a safety problem.
> A scoped access modifier is similar.


These two points are where I have to jump in. As someone who actually
teaches Swift, and not just lectures others about it on the mailing
lists, both of these arguments are terribly fallacious. Core Swift
features like optionals are fundamental to the idea of the language,
that have semantic meaning and impact on  compiled code.


People are thrilled to learn how to use enums because they make for a
better time writing code. These access modifier are can only charitably
be called code flavor. I have spent entire weeks of class trying to
extoll the benefits, so breathlessly shared on these mailing lists, of
how beautiful it is to have a scoped access level. I have yet to
succeed. They frustrate readers and they are a constant source of
roadblocks for the inexperienced.


Segregating private and fileprivate are, at best, a distraction, and at
worst are actively imposing on all of us the personal code style
preferences of those that were most active on the mailing lists while
Swift 2 was open.


It doesn't matter if desire for using extensions is the root of the
problem. Swift should only impose a preference when it's important to
the speed, functionality, and safety of the language. I have yet to be
convinced that there's a benefit to a scoped access level that fits
anywhere in there.


Best,

  Zach Waldowski

  z...@waldowski.me




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

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford 
wrote:

> I am confused by this response. An argument in _support_ of new `private`
> was that it is more in line with expectations of users coming from other
> languages. In other some cases, such an argument might have its place.
> However, as others have pointed out on this list, those other languages
> don't have facilities like Swift's extensions, and therefore it was not a
> very strong argument for new `private` to say that it better aligns with
> user expectations coming from other languages.
>
> The underlying issue here (which I have now identified, thanks!) is what
> motivates the use of extensions.  That question predates proposals, but the
> Swift book provides the following motivation, which I have numbered for
> ease of reference:
>
> 1. Extensions add new functionality to an existing class, structure,
> enumeration, or protocol type.
>
> 2. This includes the ability to extend types for which you do not have
> access to the original source code (known as retroactive modeling).
>
> 3. Extensions are similar to categories in Objective-C.
>
> It seems to me this motivation contemplates use “at some distance”, that
> is we intend to create some semantically meaningful separation between the
> declaration and the extension(s).  If we did not we could use MARK or some
> other comment-based scheme to organize our class.
>
> 2 is explicitly at great distance, so we know the distance motivation is
> well within scope.  1 refers to “an existing” type which implies a certain
> level of functionality in the unextended type, and not merely a partial
> implementation in the unextended type.  The record on 3 is more mixed (ObjC
> programmers do occasionally use categories “closely-held” to group a few
> methods together).  However ObjC also has the “distance” tradition:
> categories cannot introduce new storage even when this is technically
> trivial (within the same compilation unit for example), and this tradition
> was continued under Swift with the new ABI.
>
> What I am suggesting is that the primary design purpose of an extension is
> to create semantic distance between a declaration and the functionality
> being added.
>

I'm not sure it is necessary for extensions to have a "primary design
purpose." They serve many purposes. One use I have for them is as follows:

```
struct A {
  // Stuff here constitutes the "raison d'etre" for A.
}

extension A : B {
  // In the course of implementing `A`, I have discovered that
  // `A` can fulfill the semantic guarantees of `B`, and in fact
  // fulfills most of them already.
  //
  // So, I conform to B, as in so doing there are some practical
  // advantages, such as gaining some default implementations.
  //
  // But, to conform, I may need to implement some methods
  // not really essential for a functional `A`, but required nonetheless
  // to conform to `B`.
  //
  // I implement them here in an extension; in so doing, I express
  // the idea that I have, after implementing `A`, discovered its
  // conformance to `B`, and I am here supplying the remaining
  // implementations necessary for that conformance.
  //
  // That is, if `B` did not exist, neither would these functions here.
  // But there may be some requirements of `B` that would be
  // implemented in `A` whether or not `B` exists.
  // Those are implemented above, in `struct A { ... }`.
}
```

I find this to be an eloquent way to separate concerns. It is a common
pattern encouraged by code I admire written by others more skilled than me
in Swift.

A mechanism to hide variables from extensions is something that *furthers*
> this design goal of extensions, rather than contradicts it.
>

This, I suppose, is an argument for you to take up with Charles.


> I understand that some people use extensions as sort of an imitation
> “partial class” but they simply aren’t (no storage) and we should introduce
> a new feature if we want to have them.
>
> A core team member (I'm blanking on who) has pointed out that, in the end,
> the only necessary access modifiers are public and not public (spelled
> "internal" in Swift).
>
>
> It is not clear to me how this squares with the decision in SE-0025 that
> other access modifiers were necessary.  Can you clarify?
>

Why do you think SE-0025 decided that other access modifiers are necessary?
It merely decided that having four was deemed, on balance, superior to
having three. But the minimum number of access modifiers is, by definition,
two. In the case of Swift those essentially have to be at the module
boundary. Anything more finely diced than that and you are balancing
expressivity and complexity. I would not be opposed, incidentally, to
stripping back access modifiers to two: `internal` (or maybe eliminate that
explicit annotation altogether) and `public`.

When new `private` and `fileprivate` were shipped, there were numerous
> questions asked by users on forums such as Stack Overflow

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

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> So, if four/five access modifiers are too many, which one is carrying the 
> least weight? Which one could be removed to simplify the scheme while 
> maintaining the most expressiveness? Which one doesn't fulfill even its own 
> stated goals? Well, one of the key goals of `private` was to allow members to 
> be encapsulated within an extension, hidden even from the type being extended 
> (and vice versa for members defined in the type). It says so in the first 
> sentence of SE-0025. As seen above in my discussion with Charles Srstka, even 
> supporters of `private` disagree with that motivation to begin with. The 
> kicker is, _it also doesn't work_. Try, for instance:
> 
> ```
> struct Foo {
>   private var bar: Int { return 42 }
> }
> 
> extension Foo {
>   private var bar: Int { return 43 }
> }
> ```
> 
> The code above should compile and does not. If I understood correctly the 
> explanation from a core team member on this list, it's unclear if it can be 
> made to work without changing how mangling works, which I believe impacts ABI 
> and is not trivial at all. Thus, (a) even proponents of new `private` 
> disagree on one of two key goals stated for new `private`; (b) that goal was 
> never accomplished, and making it work is not trivial; (c) no one even 
> complained about it, suggesting that it was a low-yield goal in the first 
> place.

Multiple people have already brought up cases in which they are using 
‘private’. The repeated mention of another, unrelated use case that was 
mentioned in the SE-0025 proposal does not invalidate the real-world use cases 
which have been presented. In fact, it rather makes it appear as if the 
motivation to remove ‘private’ is based on a strange invocation of the 
appeal-to-authority fallacy, rather than an actual improvement to the language.

Many people used to argue against early returns as being tantamount to 
littering one’s code with GOTO statements willy-nilly, instead advocating for 
assigning to a return variable which would then be returned in the last line of 
the function. Swift explicitly rejects this view, offering constructs such as 
the guard statement and the error-handling mechanism which specifically 
encourage early returns. However, I don’t see people using the non-acceptance 
of this particular argument against GOTOs as an argument for eliminating all 
structured flow control from the language.

Charles

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

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

[Drew Crawford via swift-evolution]

I am confused by this response. An argument in _support_ of new `private` was 
that it is more in line with expectations of users coming from other languages. 
In other some cases, such an argument might have its place. However, as others 
have pointed out on this list, those other languages don't have facilities like 
Swift's extensions, and therefore it was not a very strong argument for new 
`private` to say that it better aligns with user expectations coming from other 
languages.
The underlying issue here (which I have now identified, thanks!) is what 
motivates the use of extensions.  That question predates proposals, but the 
Swift book provides the following motivation, which I have numbered for ease of 
reference:

1. Extensions add new functionality to an existing class, structure, 
enumeration, or protocol type. 
2. This includes the ability to extend types for which you do not have access 
to the original source code (known as retroactive modeling). 

3. Extensions are similar to categories in Objective-C.

It seems to me this motivation contemplates use “at some distance”, that is we 
intend to create some semantically meaningful separation between the 
declaration and the extension(s).  If we did not we could use MARK or some 
other comment-based scheme to organize our class.

2 is explicitly at great distance, so we know the distance motivation is well 
within scope.  1 refers to “an existing” type which implies a certain level of 
functionality in the unextended type, and not merely a partial implementation 
in the unextended type.  The record on 3 is more mixed (ObjC programmers do 
occasionally use categories “closely-held” to group a few methods together).  
However ObjC also has the “distance” tradition: categories cannot introduce new 
storage even when this is technically trivial (within the same compilation unit 
for example), and this tradition was continued under Swift with the new ABI.

What I am suggesting is that the primary design purpose of an extension is to 
create semantic distance between a declaration and the functionality being 
added.  A mechanism to hide variables from extensions is something that 
*furthers* this design goal of extensions, rather than contradicts it.

I understand that some people use extensions as sort of an imitation “partial 
class” but they simply aren’t (no storage) and we should introduce a new 
feature if we want to have them.

A core team member (I'm blanking on who) has pointed out that, in the end, the 
only necessary access modifiers are public and not public (spelled "internal" 
in Swift).

It is not clear to me how this squares with the decision in SE-0025 that other 
access modifiers were necessary.  Can you clarify?

When new `private` and `fileprivate` were shipped, there were numerous 
questions asked by users on forums such as Stack Overflow

And before they were shipped, there were people asking for a scoped modifier.  
And when we change them again, what questions will that generate?  So I don’t 
see what we are accomplishing with this line of inquiry.

You see the new access modifiers described, for example, as something that 
"take[s] some getting used to." Rather damning as a euphemism, don't you think? 
Not at all.  We could describe strong typing, or optionals, enums, pattern 
matching, etc., in this way.  ARC in particular is “difficult to teach” but we 
should not get rid of it, it solves a safety problem.  A scoped access modifier 
is similar.

When the Swift core team approved the proposal, they expressed the belief that 
`fileprivate` would be rarely used. This has turned out plainly and 
indisputably not to be true. It is clear that they expected Swift to have, 
after SE-0025 (and before `open`), three commonly used access modifiers and one 
vestigial one. Instead we have four/five commonly used access modifiers. Thus, 
the complexity of the current system is _not_ what was envisioned at the time 
of approval for SE-0025, and the resulting system should be re-evaluated in 
light of this real-world data. 

The only citation I can find on this topic is the cryptic “fileprivate is 
rarely needed” in the context of “rare enough to be explicit”.   I submit that 
according to previously-presented data, I do use it rarely, less often than the 
other modifiers, certainly in a manner consistent with being explicit.  I do 
not see how we jump from that fact pattern to “plainly and indisputably… _not_ 
what was envisioned at the time”.  It is not plain and I do dispute it.

The code above should compile and does not.

It is not clear to me how this is especially relevant.  The point of a scoped 
access modifier is to prevent programs from compiling when they should not.  
Here is a program that does not compile when it should; that’s a bug, but it 
doesn’t go to whether the scoped people are caught with their pants down or 
working from bad safety assumptions.  It’s just a complier crasher.

(a) even proponents of new `private` 

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 22:49, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> That’s why protected (a feature) is on the commonly rejected proposals list
> 
> 
> Unless you’re referring to a different “commonly rejected proposals” list 
> than the one below, this does not appear to be true:
> 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
> 

Perceptions and sometimes... wishful thinking ;).

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

[Charles Srstka via swift-evolution]

> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution 
>  wrote:
> 
> That’s why protected (a feature) is on the commonly rejected proposals list


Unless you’re referring to a different “commonly rejected proposals” list than 
the one below, this does not appear to be true:

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md 


Charles

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

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

[David Hart via swift-evolution]

> On 21 Mar 2017, at 21:59, Drew Crawford  wrote:
> 
>>  The arguments for the revert are in the proposal and in the discussions in 
>> this thread.
> 
> 
> What is in the proposal and this thread are a set of opinions, e.g.
> 
> * "the access level change of SE-0025 was met with dissatisfaction by a 
> substantial proportion of the general Swift community."
> * "Those changes can be viewed as actively harmful,”
> * "it is extremely common to use several extensions within a file.”
> * “[existing regime] encourages overuse of scoped access control”
> * “[fileprivate is the] more reasonable default”
> 
> I am asking for the arguments or evidence that led you or others to these 
> opinions.  I understand that you and others believe them, but you understand 
> that they are now a matter of debate. We are not going to reach any mutual 
> understanding just asserting things we believe.  The underlying evidence is 
> what would be necessary to convince others to our point of view.  I am trying 
> to ascertain what that evidence is.
> 
>> > It has pointed quite a few times by core team members that comparison to 
>> > languages is not a very strong arguments, 
> 
> 
> The context here is that you presented an argument that Swift’s “private” was 
> confusing to users of other languages:
> 
> > In most languages, that keyword is “private” so its valid to say that 
> > newcomers to the language will “default” to using that one. 
> 
> If you no longer think that argument is strong because it relies on a 
> comparison to other languages, then we agree :-)  But in that case we lose an 
> argument for this proposal.  The reason we are talking about other languages 
> is because that was an argument advanced to support the proposal.

Excuse me, I did not express my point well. What I meant is that wanting a 
feature in Swift because it exists in another language has not been a very 
strong argument. But contrarily, making Swift familiar to users of other 
languages because it uses similar concepts or keywords is a different story. 
That’s why protected (a feature) is on the commonly rejected proposals list, 
because it doesn’t fit with Swift even though it exists in other languages. 
But, on the other hand, keywords like try/throws (syntax) have been used 
despite the fact that Swift doesn’t have exceptions specifically to feel 
familiar to newcomers.

In that regard, wanted the scoped-private private (feature) in Swift because 
other languages have it, seems to me like a weaker argument than the argument 
that the private keyword (syntax) brings familiarity.

>> > Some people used the for(;;) loop, the ++ operator, var parameters.
> 
> 
> In those cases, there was extensive discussion of how to achieve the things 
> people were achieving with those features with alternative patterns. var 
> parameters for example have a 1LOC workaround to achieve the previous 
> semantics, ++ had two characters, for(;;) was slightly trickier but we had a 
> clear concept of the scope of the impact. So far as I’m aware, the only 
> suggestion to people who currently use a scoped access modifier is to stop 
> having their problems. So the circumstances of earlier removals and this one 
> are very different.
> 
>> > • either a programmer ... will use private as often as possible
>> > • or a programmer will … use fileprivate all the time 
> 
> There is also the possibility that a programmer considers which modifier is 
> appropriate for the code they are writing.  You "argue that... is very rare” 
> but I still am not sure what this argument is or what led you or others to 
> this conclusion.
> 
> On March 21, 2017 at 1:41:48 PM, David Hart (da...@hartbit.com 
> ) wrote:
> 
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> On 21 Mar 2017, at 16:57, Drew Crawford > > wrote:
>> 
>>> 
>>> 
 > I’m not arguing that it is less or more than a majority. I’m just saying 
 > that we’ve seen a lot of talk against the original change.
>>> 
>>> This proposal asks us to balance the convenience of one group 
>>> (extension-writers) against the existence of another (scoped-access users). 
>>>  To do that, we need a clear idea of the composition of both groups.
>>> 
>>> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
>>> was not good enough when we introduced the feature, that required argument 
>>> and clear use-cases.
>>> 
>> "A lot of talk" is not the evidence supporting the proposal: it's just a 
>> warning that something may be very controversial among the community. The 
>> arguments for the revert are in the proposal and in the discussions in this 
>> thread.
>> 
 > By default, I did not mean the syntactic default of the language but the 
 > access modifier users will use “by default” when trying to restrict 
 > visibility. In most languages, that keyword is “private” so its valid to 
 > say that 

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

[Xiaodi Wu via swift-evolution]

On Tue, Mar 21, 2017 at 3:59 PM, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

>  The arguments for the revert are in the proposal and in the discussions
> in this thread.
>
>
> What is in the proposal and this thread are a set of opinions, e.g.
>
> * "the access level change of SE-0025 was met with dissatisfaction by a
> substantial proportion of the general Swift community."
> * "Those changes can be viewed as actively harmful,”
> * "it is extremely common to use several extensions within a file.”
> * “[existing regime] encourages overuse of scoped access control”
> * “[fileprivate is the] more reasonable default”
>
> I am asking for the arguments or evidence that led you or others to these
> opinions.  I understand that you and others believe them, but you
> understand that they are now a matter of debate. We are not going to reach
> any mutual understanding just asserting things we believe.  The underlying
> evidence is what would be necessary to convince others to our point of
> view.  I am trying to ascertain what that evidence is.
>
> > It has pointed quite a few times by core team members that comparison to
> languages is not a very strong arguments,
>
>
> The context here is that you presented an argument that Swift’s “private”
> was confusing to users of other languages:
>
> > In most languages, that keyword is “private” so its valid to say that
> newcomers to the language will “default” to using that one.
>
> If you no longer think that argument is strong because it relies on a
> comparison to other languages, then we agree :-)  But in that case we lose
> an argument for this proposal.  The reason we are talking about other
> languages is because that was an argument advanced to support the proposal.
>
>
I am confused by this response. An argument in _support_ of new `private`
was that it is more in line with expectations of users coming from other
languages. In other some cases, such an argument might have its place.
However, as others have pointed out on this list, those other languages
don't have facilities like Swift's extensions, and therefore it was not a
very strong argument for new `private` to say that it better aligns with
user expectations coming from other languages.


> > Some people used the for(;;) loop, the ++ operator, var parameters.
>
>
> In those cases, there was extensive discussion of how to achieve the
> things people were achieving with those features with alternative patterns.
> var parameters for example have a 1LOC workaround to achieve the previous
> semantics, ++ had two characters, for(;;) was slightly trickier but we had
> a clear concept of the scope of the impact. So far as I’m aware, the only
> suggestion to people who currently use a scoped access modifier is to stop
> having their problems.
>

You've given one example of code that takes advantage of new `private`. As
far as I can see, in that example, you can rename `private func prune` to
`private func _prune` and have no further problems. That is to say, the
workaround is a single character at each use site, which by your metric
makes this proposal half as onerous as removing `++`.

So the circumstances of earlier removals and this one are very different.
>
> > • either a programmer ... will use private as often as possible
> > • or a programmer will … use fileprivate all the time
>
> There is also the possibility that a programmer considers which modifier
> is appropriate for the code they are writing.  You "argue that... is very
> rare” but I still am not sure what this argument is or what led you or
> others to this conclusion.
>

I'm not enamored of the argumentation in the proposal set out above. But
since you are saying that you're not sure how anybody came to support this
proposal, here's how I arrived at supporting it:

A core team member (I'm blanking on who) has pointed out that, in the end,
the only necessary access modifiers are public and not public (spelled
"internal" in Swift). It has been my understanding that supporting all
possible ways of hiding a member from arbitrary other code within the same
module is a _non-goal_. There have been numerous attempts at designing
elaborate access modifier schemes that make this possible with friends,
protected, shared, what-have-you, and I try to bring up this point each
time.

Beyond the two absolutely essential access modifiers, anything else does
not add to safety as the term is understood in Swift, but rather improves
developer experience. But what is gained in terms of developer experience
with each additional access modifier (due to increased expressiveness) is
offset by what is lost due to complexity. So then the question is: what is
the ideal number of access modifiers? is it two? three? four? five? six?
eight? ten? twelve?

When new `private` and `fileprivate` were shipped, there were numerous
questions asked by users on forums such as Stack Overflow (easily googled;
just as a single example:

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

[Matthew Johnson via swift-evolution]

Sent from my iPhone

> On Mar 21, 2017, at 4:48 PM, Jose Cheyo Jimenez  wrote:
> 
> 
>>> On Mar 21, 2017, at 2:33 PM, Matthew Johnson  wrote:
>>> 
>>> 
 On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez  
 wrote:
 
 
> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  wrote:
> 
>> 
>> 
>>> > I’m not arguing that it is less or more than a majority. I’m just 
>>> > saying that we’ve seen a lot of talk against the original change.
>> 
>> This proposal asks us to balance the convenience of one group 
>> (extension-writers) against the existence of another (scoped-access 
>> users).  To do that, we need a clear idea of the composition of both 
>> groups.
>> 
>> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
>> was not good enough when we introduced the feature, that required 
>> argument and clear use-cases.
>> 
> "A lot of talk" is not the evidence supporting the proposal: it's just a 
> warning that something may be very controversial among the community. The 
> arguments for the revert are in the proposal and in the discussions in 
> this thread.
> 
>>> > By default, I did not mean the syntactic default of the language but 
>>> > the access modifier users will use “by default” when trying to 
>>> > restrict visibility. In most languages, that keyword is “private” so 
>>> > its valid to say that newcomers to the language will “default” to 
>>> > using that one.
>> 
>> Apologies, but I do not understand the argument:
>> 
>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>> “internal”)
>> The user *chooses* private because of familiarity from another language
>> The user is then surprised that their choice of private indeed 
>> restricted the visibility, thus achieving their goal?
>> What language does the user come from in which “private” is 
>> file-visible?  It isn’t Java, C++, or PHP.  C#’s “partial” is the 
>> closest I can think of, and it isn’t at all close.
> 
> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, especially when Swift does 
> things differently for a good reason. I can't stop from quoting Xiaodi 
> from a month back:
> 
> «The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility.» -- Xiaodi
> 
>> A user who wants a middle-ground visibility would “default” to 
>> “protected”, “friend”, “partial”, or similar.  After that does not 
>> compile, they will use google to find a middle-road visibility keyword, 
>> for which the only candidate is “fileprivate”.  But they will not choose 
>> “private”, it’s just not a reasonable expectation of what the keyword 
>> means to a new Swift developer.
>> 
>> The popularity of private “as a default” is simply because many users 
>> prefer to hide their implementation details as a matter of routine code 
>> hygiene.  Redefining private in order to thwart their code hygiene goal 
>> seems extreme.
> 
> The point is that keeping both private and fileprivate feels like an 
> un-necessary complication:
> 
> • either a programmer falls on your side of the fence and will use 
> private as often as possible and relegate to fileprivate when the design 
> leaves no other choice. At that point it feels like a language wart.
> • or a programmer will fall on my side of the fence and use fileprivate 
> all the time and the language feels like it has an unnecessary access 
> modifier.
> 
> I'd argue that the cases when a programmer will use both meaningfully is 
> very rare. As a consequence, we should try to only keep one. Removing 
> fileprivate is a no-go with extensions so that leaves us with removing 
> private.
 
 Removing scoped access is a no-go if we consider tightly encapsulating 
 invariant-preserving state to be an important feature.  The fact is that 
 both features can be used meaningfully.  The fact that some people choose 
 not to do this is not an argument against the features being available.  
 It is an opportunity to encourage people to thing more carefully about why 
 they are encapsulating something.  
>>> 
>>> I understand the bigger picture you are getting at but the scope access you 
>>> have envisioned should not 

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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 2:33 PM, Matthew Johnson  wrote:
> 
>> 
>> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez > > wrote:
>> 
>> 
>>> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
 > wrote:
 
 
 
 
 
 Sent from my iPhone
 On 21 Mar 2017, at 16:57, Drew Crawford > wrote:
 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just 
>> > saying that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access 
> users).  To do that, we need a clear idea of the composition of both 
> groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
> was not good enough when we introduced the feature, that required 
> argument and clear use-cases.
> 
 "A lot of talk" is not the evidence supporting the proposal: it's just a 
 warning that something may be very controversial among the community. The 
 arguments for the revert are in the proposal and in the discussions in 
 this thread.
 
>> > By default, I did not mean the syntactic default of the language but 
>> > the access modifier users will use “by default” when trying to 
>> > restrict visibility. In most languages, that keyword is “private” so 
>> > its valid to say that newcomers to the language will “default” to 
>> > using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted 
> the visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible? 
>  It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think 
> of, and it isn’t at all close.
 
 It has pointed quite a few times by core team members that comparison to 
 languages is not a very strong arguments, especially when Swift does 
 things differently for a good reason. I can't stop from quoting Xiaodi 
 from a month back:
 
 «The beauty of Swift 2's access modifiers was that they were based around 
 files and modules, explicitly rejecting types and scopes as units for 
 determining visibility.» -- Xiaodi
 
> A user who wants a middle-ground visibility would “default” to 
> “protected”, “friend”, “partial”, or similar.  After that does not 
> compile, they will use google to find a middle-road visibility keyword, 
> for which the only candidate is “fileprivate”.  But they will not choose 
> “private”, it’s just not a reasonable expectation of what the keyword 
> means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users 
> prefer to hide their implementation details as a matter of routine code 
> hygiene.  Redefining private in order to thwart their code hygiene goal 
> seems extreme.
 
 The point is that keeping both private and fileprivate feels like an 
 un-necessary complication:
 
 • either a programmer falls on your side of the fence and will use private 
 as often as possible and relegate to fileprivate when the design leaves no 
 other choice. At that point it feels like a language wart.
 • or a programmer will fall on my side of the fence and use fileprivate 
 all the time and the language feels like it has an unnecessary access 
 modifier.
 
 I'd argue that the cases when a programmer will use both meaningfully is 
 very rare. As a consequence, we should try to only keep one. Removing 
 fileprivate is a no-go with extensions so that leaves us with removing 
 private.
>>> 
>>> Removing scoped access is a no-go if we consider tightly encapsulating 
>>> invariant-preserving state to be an important feature.  The fact is that 
>>> both features can be used meaningfully.  The fact that some people choose 
>>> not to do this is not an argument against the features being available.  It 
>>> is an opportunity to encourage people to thing more carefully about why 
>>> they are encapsulating something.  
>> 
>> I understand the bigger picture you are getting at but the scope access you 
>> have envisioned should not be called private. 
> 
> I don’t disagree with this.  I’m fine with renaming it 

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

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez  wrote:
> 
> 
>> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> On 21 Mar 2017, at 16:57, Drew Crawford >> > wrote:
>>> 
 
 
> > I’m not arguing that it is less or more than a majority. I’m just 
> > saying that we’ve seen a lot of talk against the original change.
 
 This proposal asks us to balance the convenience of one group 
 (extension-writers) against the existence of another (scoped-access 
 users).  To do that, we need a clear idea of the composition of both 
 groups.
 
 “A lot of talk” is not the evidentiary standard to remove a feature.  It 
 was not good enough when we introduced the feature, that required argument 
 and clear use-cases.
 
>>> "A lot of talk" is not the evidence supporting the proposal: it's just a 
>>> warning that something may be very controversial among the community. The 
>>> arguments for the revert are in the proposal and in the discussions in this 
>>> thread.
>>> 
> > By default, I did not mean the syntactic default of the language but 
> > the access modifier users will use “by default” when trying to restrict 
> > visibility. In most languages, that keyword is “private” so its valid 
> > to say that newcomers to the language will “default” to using that one.
 
 Apologies, but I do not understand the argument:
 
 A user wants to restrict visibility (e.g. they are dissatisfied with 
 “internal”)
 The user *chooses* private because of familiarity from another language
 The user is then surprised that their choice of private indeed restricted 
 the visibility, thus achieving their goal?
 What language does the user come from in which “private” is file-visible?  
 It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
 and it isn’t at all close.
>>> 
>>> It has pointed quite a few times by core team members that comparison to 
>>> languages is not a very strong arguments, especially when Swift does things 
>>> differently for a good reason. I can't stop from quoting Xiaodi from a 
>>> month back:
>>> 
>>> «The beauty of Swift 2's access modifiers was that they were based around 
>>> files and modules, explicitly rejecting types and scopes as units for 
>>> determining visibility.» -- Xiaodi
>>> 
 A user who wants a middle-ground visibility would “default” to 
 “protected”, “friend”, “partial”, or similar.  After that does not 
 compile, they will use google to find a middle-road visibility keyword, 
 for which the only candidate is “fileprivate”.  But they will not choose 
 “private”, it’s just not a reasonable expectation of what the keyword 
 means to a new Swift developer.
 
 The popularity of private “as a default” is simply because many users 
 prefer to hide their implementation details as a matter of routine code 
 hygiene.  Redefining private in order to thwart their code hygiene goal 
 seems extreme.
>>> 
>>> The point is that keeping both private and fileprivate feels like an 
>>> un-necessary complication:
>>> 
>>> • either a programmer falls on your side of the fence and will use private 
>>> as often as possible and relegate to fileprivate when the design leaves no 
>>> other choice. At that point it feels like a language wart.
>>> • or a programmer will fall on my side of the fence and use fileprivate all 
>>> the time and the language feels like it has an unnecessary access modifier.
>>> 
>>> I'd argue that the cases when a programmer will use both meaningfully is 
>>> very rare. As a consequence, we should try to only keep one. Removing 
>>> fileprivate is a no-go with extensions so that leaves us with removing 
>>> private.
>> 
>> Removing scoped access is a no-go if we consider tightly encapsulating 
>> invariant-preserving state to be an important feature.  The fact is that 
>> both features can be used meaningfully.  The fact that some people choose 
>> not to do this is not an argument against the features being available.  It 
>> is an opportunity to encourage people to thing more carefully about why they 
>> are encapsulating something.  
> 
> I understand the bigger picture you are getting at but the scope access you 
> have envisioned should not be called private. 

I don’t disagree with this.  I’m fine with renaming it and allowing `private` 
to mean file-level scope.

> 
> In order to get scope access to a place where it is more useful we have to 
> remove it.

No we don’t.  We could remove it and re-add it but that would be crazy.  We 
would break a 

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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>> 
>> 
>> Sent from my iPhone
>> On 21 Mar 2017, at 16:57, Drew Crawford > > wrote:
>> 
>>> 
>>> 
 > I’m not arguing that it is less or more than a majority. I’m just saying 
 > that we’ve seen a lot of talk against the original change.
>>> 
>>> This proposal asks us to balance the convenience of one group 
>>> (extension-writers) against the existence of another (scoped-access users). 
>>>  To do that, we need a clear idea of the composition of both groups.
>>> 
>>> “A lot of talk” is not the evidentiary standard to remove a feature.  It 
>>> was not good enough when we introduced the feature, that required argument 
>>> and clear use-cases.
>>> 
>> "A lot of talk" is not the evidence supporting the proposal: it's just a 
>> warning that something may be very controversial among the community. The 
>> arguments for the revert are in the proposal and in the discussions in this 
>> thread.
>> 
 > By default, I did not mean the syntactic default of the language but the 
 > access modifier users will use “by default” when trying to restrict 
 > visibility. In most languages, that keyword is “private” so its valid to 
 > say that newcomers to the language will “default” to using that one.
>>> 
>>> Apologies, but I do not understand the argument:
>>> 
>>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>>> “internal”)
>>> The user *chooses* private because of familiarity from another language
>>> The user is then surprised that their choice of private indeed restricted 
>>> the visibility, thus achieving their goal?
>>> What language does the user come from in which “private” is file-visible?  
>>> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
>>> and it isn’t at all close.
>> 
>> It has pointed quite a few times by core team members that comparison to 
>> languages is not a very strong arguments, especially when Swift does things 
>> differently for a good reason. I can't stop from quoting Xiaodi from a month 
>> back:
>> 
>> «The beauty of Swift 2's access modifiers was that they were based around 
>> files and modules, explicitly rejecting types and scopes as units for 
>> determining visibility.» -- Xiaodi
>> 
>>> A user who wants a middle-ground visibility would “default” to “protected”, 
>>> “friend”, “partial”, or similar.  After that does not compile, they will 
>>> use google to find a middle-road visibility keyword, for which the only 
>>> candidate is “fileprivate”.  But they will not choose “private”, it’s just 
>>> not a reasonable expectation of what the keyword means to a new Swift 
>>> developer.
>>> 
>>> The popularity of private “as a default” is simply because many users 
>>> prefer to hide their implementation details as a matter of routine code 
>>> hygiene.  Redefining private in order to thwart their code hygiene goal 
>>> seems extreme.
>> 
>> The point is that keeping both private and fileprivate feels like an 
>> un-necessary complication:
>> 
>> • either a programmer falls on your side of the fence and will use private 
>> as often as possible and relegate to fileprivate when the design leaves no 
>> other choice. At that point it feels like a language wart.
>> • or a programmer will fall on my side of the fence and use fileprivate all 
>> the time and the language feels like it has an unnecessary access modifier.
>> 
>> I'd argue that the cases when a programmer will use both meaningfully is 
>> very rare. As a consequence, we should try to only keep one. Removing 
>> fileprivate is a no-go with extensions so that leaves us with removing 
>> private.
> 
> Removing scoped access is a no-go if we consider tightly encapsulating 
> invariant-preserving state to be an important feature.  The fact is that both 
> features can be used meaningfully.  The fact that some people choose not to 
> do this is not an argument against the features being available.  It is an 
> opportunity to encourage people to thing more carefully about why they are 
> encapsulating something.  

I understand the bigger picture you are getting at but the scope access you 
have envisioned should not be called private. 

In order to get scope access to a place where it is more useful we have to 
remove it.

I don’t mind if scope access is kept but it must have a different name and that 
should be a different limited scope proposal. 

Opposing SE-0159 will make it much harder to redefine scope access.


> 
> A programmer has to make a conscious decision to give a declaration 
> visibility other than internal.  If they have trouble identifying whether 
> file or scoped access is appropriate this indicates they don’t really 
> 

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

[Drew Crawford via swift-evolution]

 The arguments for the revert are in the proposal and in the discussions in 
this thread.

What is in the proposal and this thread are a set of opinions, e.g.

* "the access level change of SE-0025 was met with dissatisfaction by a 
substantial proportion of the general Swift community."
* "Those changes can be viewed as actively harmful,”
* "it is extremely common to use several extensions within a file.”
* “[existing regime] encourages overuse of scoped access control”
* “[fileprivate is the] more reasonable default”

I am asking for the arguments or evidence that led you or others to these 
opinions.  I understand that you and others believe them, but you understand 
that they are now a matter of debate. We are not going to reach any mutual 
understanding just asserting things we believe.  The underlying evidence is 
what would be necessary to convince others to our point of view.  I am trying 
to ascertain what that evidence is.

> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, 

The context here is that you presented an argument that Swift’s “private” was 
confusing to users of other languages:

> In most languages, that keyword is “private” so its valid to say that 
> newcomers to the language will “default” to using that one. 

If you no longer think that argument is strong because it relies on a 
comparison to other languages, then we agree :-)  But in that case we lose an 
argument for this proposal.  The reason we are talking about other languages is 
because that was an argument advanced to support the proposal.

> Some people used the for(;;) loop, the ++ operator, var parameters.

In those cases, there was extensive discussion of how to achieve the things 
people were achieving with those features with alternative patterns. var 
parameters for example have a 1LOC workaround to achieve the previous 
semantics, ++ had two characters, for(;;) was slightly trickier but we had a 
clear concept of the scope of the impact. So far as I’m aware, the only 
suggestion to people who currently use a scoped access modifier is to stop 
having their problems. So the circumstances of earlier removals and this one 
are very different.

> • either a programmer ... will use private as often as possible
> • or a programmer will … use fileprivate all the time 
There is also the possibility that a programmer considers which modifier is 
appropriate for the code they are writing.  You "argue that... is very rare” 
but I still am not sure what this argument is or what led you or others to this 
conclusion.

On March 21, 2017 at 1:41:48 PM, David Hart (da...@hartbit.com) wrote:





Sent from my iPhone
On 21 Mar 2017, at 16:57, Drew Crawford  wrote:



> I’m not arguing that it is less or more than a majority. I’m just saying that 
> we’ve seen a lot of talk against the original change.
This proposal asks us to balance the convenience of one group 
(extension-writers) against the existence of another (scoped-access users).  To 
do that, we need a clear idea of the composition of both groups.

“A lot of talk” is not the evidentiary standard to remove a feature.  It was 
not good enough when we introduced the feature, that required argument and 
clear use-cases.

"A lot of talk" is not the evidence supporting the proposal: it's just a 
warning that something may be very controversial among the community. The 
arguments for the revert are in the proposal and in the discussions in this 
thread.

> By default, I did not mean the syntactic default of the language but the 
> access modifier users will use “by default” when trying to restrict 
> visibility. In most languages, that keyword is “private” so its valid to say 
> that newcomers to the language will “default” to using that one.
Apologies, but I do not understand the argument:

A user wants to restrict visibility (e.g. they are dissatisfied with “internal”)
The user *chooses* private because of familiarity from another language
The user is then surprised that their choice of private indeed restricted the 
visibility, thus achieving their goal?
What language does the user come from in which “private” is file-visible?  It 
isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and it 
isn’t at all close.

It has pointed quite a few times by core team members that comparison to 
languages is not a very strong arguments, especially when Swift does things 
differently for a good reason. I can't stop from quoting Xiaodi from a month 
back:

«The beauty of Swift 2's access modifiers was that they were based around files 
and modules, explicitly rejecting types and scopes as units for determining 
visibility.» -- Xiaodi

A user who wants a middle-ground visibility would “default” to “protected”, 
“friend”, “partial”, or similar.  After that does not compile, they will use 
google to find a middle-road visibility keyword, for which the only candidate 
is 

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 18:41, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  wrote:
> 
>> 
>> 
>>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>>> > that we’ve seen a lot of talk against the original change.
>> 
>> This proposal asks us to balance the convenience of one group 
>> (extension-writers) against the existence of another (scoped-access users).  
>> To do that, we need a clear idea of the composition of both groups.
>> 
>> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
>> not good enough when we introduced the feature, that required argument and 
>> clear use-cases.
>> 
> "A lot of talk" is not the evidence supporting the proposal: it's just a 
> warning that something may be very controversial among the community. The 
> arguments for the revert are in the proposal and in the discussions in this 
> thread.
> 
>>> > By default, I did not mean the syntactic default of the language but the 
>>> > access modifier users will use “by default” when trying to restrict 
>>> > visibility. In most languages, that keyword is “private” so its valid to 
>>> > say that newcomers to the language will “default” to using that one.
>> 
>> Apologies, but I do not understand the argument:
>> 
>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>> “internal”)
>> The user *chooses* private because of familiarity from another language
>> The user is then surprised that their choice of private indeed restricted 
>> the visibility, thus achieving their goal?
>> What language does the user come from in which “private” is file-visible?  
>> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
>> and it isn’t at all close.
> 
> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, especially when Swift does things 
> differently for a good reason. I can't stop from quoting Xiaodi from a month 
> back:
> 
> «The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility.» -- Xiaodi
> 

I do not see how Swift explicitly rejected both types and scope for determining 
visibility, we have private and fileprivate for a reason and they may not help 
everybody to feel Swifty or whatever that means in practice, but it allows 
others to do actual work. Having additional flexibility does not hurt people 
that want to stick with file based visibility.

None of us here is paid to write haiku/poetry code, so while beauty has a place 
it is not the necessary and sufficient condition for language features: code is 
meant to be read, refactored, and most of all shipped and debugged quickly.

>> A user who wants a middle-ground visibility would “default” to “protected”, 
>> “friend”, “partial”, or similar.  After that does not compile, they will use 
>> google to find a middle-road visibility keyword, for which the only 
>> candidate is “fileprivate”.  But they will not choose “private”, it’s just 
>> not a reasonable expectation of what the keyword means to a new Swift 
>> developer.
>> 
>> The popularity of private “as a default” is simply because many users prefer 
>> to hide their implementation details as a matter of routine code hygiene.  
>> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> The point is that keeping both private and fileprivate feels like an 
> un-necessary complication:
> 
> • either a programmer falls on your side of the fence and will use private as 
> often as possible and relegate to fileprivate when the design leaves no other 
> choice. At that point it feels like a language wart.
> • or a programmer will fall on my side of the fence and use fileprivate all 
> the time and the language feels like it has an unnecessary access modifier.
> 
> I'd argue that the cases when a programmer will use both meaningfully is very 
> rare. As a consequence, we should try to only keep one. Removing fileprivate 
> is a no-go with extensions so that leaves us with removing private.
> 
>> I agree with several here (as I did in SE-0025) that our access modifiers 
>> are not well-named.  However, that’s not the proposal in front of us.
>> 
>>> > My own statistics in my projects show the contrary. At best, this shows 
>>> > how divisive this feature is.
>> 
>> This *may* show that, if contrary statistics were presented, but that hasn’t 
>> occurred.
>> 
> I can generate statistics from my projects if you want. But it's unnecessary: 
> I haven't used private once since it's introduction in Swift 3. I don't see 
> the advantages it brings worth the trouble.
>>> In old code, statistics could be biased by the migrator having replaced all 
>>> previous instances of private by 

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

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 15:57, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>> > that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access users).  
> To do that, we need a clear idea of the composition of both groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
> not good enough when we introduced the feature, that required argument and 
> clear use-cases.
> 
>> > By default, I did not mean the syntactic default of the language but the 
>> > access modifier users will use “by default” when trying to restrict 
>> > visibility. In most languages, that keyword is “private” so its valid to 
>> > say that newcomers to the language will “default” to using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted the 
> visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible?  It 
> isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and 
> it isn’t at all close.
> 

I agree, the old change gave private a much more commonly understood and IMHO 
more understandable meaning (changing do while into repeat while is the kind of 
change I would not like to see again unless well justified :)).

> A user who wants a middle-ground visibility would “default” to “protected”, 
> “friend”, “partial”, or similar.  After that does not compile, they will use 
> google to find a middle-road visibility keyword, for which the only candidate 
> is “fileprivate”.  But they will not choose “private”, it’s just not a 
> reasonable expectation of what the keyword means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users prefer 
> to hide their implementation details as a matter of routine code hygiene.  
> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> I agree with several here (as I did in SE-0025) that our access modifiers are 
> not well-named.  However, that’s not the proposal in front of us.
> 
>> > My own statistics in my projects show the contrary. At best, this shows 
>> > how divisive this feature is.
> 
> This *may* show that, if contrary statistics were presented, but that hasn’t 
> occurred.
> 
>> In old code, statistics could be biased by the migrator having replaced all 
>> previous instances of private by fileprivate.
> 
> If the migrator migrated code to private, and it *worked* (e.g. did not 
> introduce visibility errors) this is not bias, this is a correct use of the 
> feature.
> 
>> > I'm just arguing that the additional scope-based access modifier does not 
>> > provide enough differentiation to be worth that complexity.
> 
> The only argument I have seen so far around “complexity” boils down to: “some 
> people do not use it”.  But some people *do* use it, and anyway if we are 
> going to remove all the features “not enough people” use then we are in for a 
> ride.
> 
> Swift 3 shipped, so what we are discussing now is yanking a keyword without 
> replacement.  There is code written that uses private to enforce its 
> threading or security invariants.  There is code written that uses private in 
> order to shadow another declaration.   There is code that will not compile 
> after migration. We need more than a vague fear of complexity generally to 
> throw a brick through all those windows.  That brick will introduce quite a 
> bit of complexity itself.
> 
>> Concerning the one-class-per-file argument, I would suggest this 
>> counter-argument: when working in large projects, I believe it's a good 
>> thing if the language encourages (forces is too strong a word for my taste) 
>> a one class per file structure, it's good practice.
> 
> The form of the argument is invalid.  Suppose I argued: "it’s a good thing 
> for the language to encourage one definition per class (no extensions), it’s 
> good practice.  So we do not need fileprivate.”  That would be very silly 
> (although it has already been advanced as a straw-man position elsewhere in 
> this thread). The argument that we do not need private because nobody should 
> put multiple classes in a file is equally silly. There are reasons to do so, 
> in fact one motivation was given in SE-0025:
> 
>> > Putting related APIs and/or related implementations in the same file helps 
>> > ensure consistency and reduces the time to find a particular API or 
>> > implementation. 
> 
> 
> These concerns are not resolved by arguments of the form “just don’t do that”.

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

[Michel Fortin via swift-evolution]

>   • What is your evaluation of the proposal?

Renaming `fileprivate` to `private` makes sense. In my code, I use 
`fileprivate` and `private` interchangeably, meaning that I write `private` for 
things that shouldn't be leaked to the whole module and if by chance the 
compiler complain I'll change it to `fileprivate` without a second thought. 
This tells me that I'm using the feature wrong: I should be writing 
`fileprivate` everywhere and narrowing it to `private` only where it is really 
important that I do so. But a name like `fileprivate` makes this rather 
difficult.

So I'd be glad to see that problem go away.


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

I think it is significant enough. I think the core team's evaluation for Swift 
3 that `fileprivate` would be rarely used was completely mistaken. Worse, 
forcing the use of the dirtier word `fileprivate` is draining all thoughtful 
intent from `private` in Swift 3. It's not a good thing when `private` is used 
only because it compiles and changed to `fileprivate` on a whim whenever the 
compiler complains.

While I don't have much attachment to the scoped-private concept, I'm not 
convinced its total removal is necessary either. Alternative 3 might solve this 
problem with less disruption to the language. While it offers some room to 
replicate the same problem I described above -- with different keywords -- I 
feel using a word like `scoped` would be less prone to overuse than `private` 
and therefore more truthful to the actual intent. If so, that would fix the 
problem too.

Either way, something must be done.


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

I think it does. The conflation of `private` and `fileprivate` at the top level 
of the file always sounded indicative to me of a flaw in the design. Correcting 
this would be an improvement.


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

I'm used to D where `private` has the pretty much same meaning as `fileprivate` 
in Swift. I never found that much of a problem. But I've seen similar debates 
there too.


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

I've read the proposal and most of the discussion, even though I haven't 
participated much.


-- 
Michel Fortin
https://michelf.ca

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

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

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution 
>  wrote:
> 
> 
> 
> 
> 
> Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  > wrote:
> 
>> 
>> 
>>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>>> > that we’ve seen a lot of talk against the original change.
>> 
>> This proposal asks us to balance the convenience of one group 
>> (extension-writers) against the existence of another (scoped-access users).  
>> To do that, we need a clear idea of the composition of both groups.
>> 
>> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
>> not good enough when we introduced the feature, that required argument and 
>> clear use-cases.
>> 
> "A lot of talk" is not the evidence supporting the proposal: it's just a 
> warning that something may be very controversial among the community. The 
> arguments for the revert are in the proposal and in the discussions in this 
> thread.
> 
>>> > By default, I did not mean the syntactic default of the language but the 
>>> > access modifier users will use “by default” when trying to restrict 
>>> > visibility. In most languages, that keyword is “private” so its valid to 
>>> > say that newcomers to the language will “default” to using that one.
>> 
>> Apologies, but I do not understand the argument:
>> 
>> A user wants to restrict visibility (e.g. they are dissatisfied with 
>> “internal”)
>> The user *chooses* private because of familiarity from another language
>> The user is then surprised that their choice of private indeed restricted 
>> the visibility, thus achieving their goal?
>> What language does the user come from in which “private” is file-visible?  
>> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, 
>> and it isn’t at all close.
> 
> It has pointed quite a few times by core team members that comparison to 
> languages is not a very strong arguments, especially when Swift does things 
> differently for a good reason. I can't stop from quoting Xiaodi from a month 
> back:
> 
> «The beauty of Swift 2's access modifiers was that they were based around 
> files and modules, explicitly rejecting types and scopes as units for 
> determining visibility.» -- Xiaodi
> 
>> A user who wants a middle-ground visibility would “default” to “protected”, 
>> “friend”, “partial”, or similar.  After that does not compile, they will use 
>> google to find a middle-road visibility keyword, for which the only 
>> candidate is “fileprivate”.  But they will not choose “private”, it’s just 
>> not a reasonable expectation of what the keyword means to a new Swift 
>> developer.
>> 
>> The popularity of private “as a default” is simply because many users prefer 
>> to hide their implementation details as a matter of routine code hygiene.  
>> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> The point is that keeping both private and fileprivate feels like an 
> un-necessary complication:
> 
> • either a programmer falls on your side of the fence and will use private as 
> often as possible and relegate to fileprivate when the design leaves no other 
> choice. At that point it feels like a language wart.
> • or a programmer will fall on my side of the fence and use fileprivate all 
> the time and the language feels like it has an unnecessary access modifier.
> 
> I'd argue that the cases when a programmer will use both meaningfully is very 
> rare. As a consequence, we should try to only keep one. Removing fileprivate 
> is a no-go with extensions so that leaves us with removing private.

Removing scoped access is a no-go if we consider tightly encapsulating 
invariant-preserving state to be an important feature.  The fact is that both 
features can be used meaningfully.  The fact that some people choose not to do 
this is not an argument against the features being available.  It is an 
opportunity to encourage people to thing more carefully about why they are 
encapsulating something.  

A programmer has to make a conscious decision to give a declaration visibility 
other than internal.  If they have trouble identifying whether file or scoped 
access is appropriate this indicates they don’t really understand their intent 
in encapsulating the declaration very clearly.  I don’t think it’s a bad thing 
to ask people to think about this a little bit more.  A simple guideline is to 
use file-level access unless you have a specific reason for preferring the 
tight encapsulation scoped access provides.  Both Drew and I have offered some 
examples of specific reasons for using scoped access that IMO are important 
enough that they deserve to be supported by the language.

> 
>> I agree with several here (as I did in SE-0025) that our access modifiers 
>> are not well-named.  However, that’s not the proposal in front of us.
>> 
>>> > My own statistics in my 

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

[Charlie Monroe via swift-evolution]

> On Mar 21, 2017, at 6:43 PM, Jose Cheyo Jimenez  wrote:
> 
>> 
>> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Mar 21, 2017, at 8:26 AM, Slava Pestov >> > wrote:
>>> 
 
 On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
 > wrote:
 
 -1 on this as well for similar reasons. Places where I use fileprivate 
 (aside from what was automatically migrated by Xcode) can be counted on 
 fingers of one or two hands. 
 
 I feel that this proposal is reverting something without offering an 
 alternative solution.
>>> 
>>> In what situations do you use Swift 3 private where fileprivate is not an 
>>> acceptable replacement?
>> 
>> In my usage, I very rarely use fileprivate. To back this with numbers, a 
>> recent project I developed (i.e. without Xcode's automatic migration of 
>> private -> fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 
>> uses of "private”.
> 
> Do you have a way to tell how much of the private is effectible fileprivate? 
> (top level private usage)

Yes, 19 cases (out of those 160). Mostly for private classes or 
identifiers/constants.

In another project (a framework I use in all my projects):

private (total): 335
top-level private: 65 (out of those 335)
fileprivate: 41

And I know about a place or two that's not properly written and if I refactored 
it properly, I'd get rid of another 20 fileprivates.

In my experience (for me - please don't take it as if I am judging anyone - not 
at all), the use of fileprivate indicates either improper public API (and by 
public I mean even internal - exposed out of the file); or that there could be 
other mechanisms for handling this (protected scope for subclasses/enclosing 
types).

> 
> 
> 
>> 
>> This is definitely a personal opinion, but I tend to limit access to members 
>> as much as possible to discourage/prevent their usage out of the scope they 
>> are intended for and to better design API that should be used out of the 
>> scope (public/internal). I feel this is a good thing for newcomers to a 
>> codebase (and myself coming back to a codebase after a year or two) as 
>> Xcode's autocompletion won't offer members that are not supposed to be 
>> called out of the scope (scope-private). 
>> 
>> As I've mentioned this during the discussion, I feel that current state of 
>> things encourages huge files (1000+ lines of code) as you can't define 
>> "protected" level access and migrate some of the code that implements e.g. 
>> accessibility to a different file without potentially exposing internal 
>> details to the rest of the module (if the extension in the other file needs 
>> access to private details, which is often the case).
>> 
>> I feel that if there should be a change to the access levels, it should 
>> address this as well. The current solution based on reverting the original 
>> proposal only unnecessarily exposes implementational details to the rest of 
>> the file - at least in my codebase.
>> 
>>> 
>>> Slava
>>> 
 
> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
> > wrote:
> 
> 
>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > 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
>>  
>> 
> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
> explained my concerns.
> 
> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[David Hart via swift-evolution]

Sent from my iPhone
> On 21 Mar 2017, at 16:57, Drew Crawford  wrote:
> 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>> > that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access users).  
> To do that, we need a clear idea of the composition of both groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
> not good enough when we introduced the feature, that required argument and 
> clear use-cases.
> 
"A lot of talk" is not the evidence supporting the proposal: it's just a 
warning that something may be very controversial among the community. The 
arguments for the revert are in the proposal and in the discussions in this 
thread.

>> > By default, I did not mean the syntactic default of the language but the 
>> > access modifier users will use “by default” when trying to restrict 
>> > visibility. In most languages, that keyword is “private” so its valid to 
>> > say that newcomers to the language will “default” to using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted the 
> visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible?  It 
> isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and 
> it isn’t at all close.

It has pointed quite a few times by core team members that comparison to 
languages is not a very strong arguments, especially when Swift does things 
differently for a good reason. I can't stop from quoting Xiaodi from a month 
back:

«The beauty of Swift 2's access modifiers was that they were based around files 
and modules, explicitly rejecting types and scopes as units for determining 
visibility.» -- Xiaodi

> A user who wants a middle-ground visibility would “default” to “protected”, 
> “friend”, “partial”, or similar.  After that does not compile, they will use 
> google to find a middle-road visibility keyword, for which the only candidate 
> is “fileprivate”.  But they will not choose “private”, it’s just not a 
> reasonable expectation of what the keyword means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users prefer 
> to hide their implementation details as a matter of routine code hygiene.  
> Redefining private in order to thwart their code hygiene goal seems extreme.

The point is that keeping both private and fileprivate feels like an 
un-necessary complication:

• either a programmer falls on your side of the fence and will use private as 
often as possible and relegate to fileprivate when the design leaves no other 
choice. At that point it feels like a language wart.
• or a programmer will fall on my side of the fence and use fileprivate all the 
time and the language feels like it has an unnecessary access modifier.

I'd argue that the cases when a programmer will use both meaningfully is very 
rare. As a consequence, we should try to only keep one. Removing fileprivate is 
a no-go with extensions so that leaves us with removing private.

> I agree with several here (as I did in SE-0025) that our access modifiers are 
> not well-named.  However, that’s not the proposal in front of us.
> 
>> > My own statistics in my projects show the contrary. At best, this shows 
>> > how divisive this feature is.
> 
> This *may* show that, if contrary statistics were presented, but that hasn’t 
> occurred.
> 
I can generate statistics from my projects if you want. But it's unnecessary: I 
haven't used private once since it's introduction in Swift 3. I don't see the 
advantages it brings worth the trouble.
>> In old code, statistics could be biased by the migrator having replaced all 
>> previous instances of private by fileprivate.
> 
> If the migrator migrated code to private, and it *worked* (e.g. did not 
> introduce visibility errors) this is not bias, this is a correct use of the 
> feature.
> 
The migrator migrated to fileprivate everywhere, not private, disagreeing with 
your use of fileprivate.

>> > I'm just arguing that the additional scope-based access modifier does not 
>> > provide enough differentiation to be worth that complexity.
> 
> The only argument I have seen so far around “complexity” boils down to: “some 
> people do not use it”.  But some people *do* use it, and anyway if we are 
> going to remove all the features “not enough people” use then we are in for a 
> ride.
> 
Some people used the for(;;) loop, the ++ operator, var parameters. Many other 
features were removed from Swift to simplify he language, make it more 
consistent. Those are 

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

[Jose Cheyo Jimenez via swift-evolution]

> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution 
>  wrote:
> 
> 
>> On Mar 21, 2017, at 8:26 AM, Slava Pestov > > wrote:
>> 
>>> 
>>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
>>> > wrote:
>>> 
>>> -1 on this as well for similar reasons. Places where I use fileprivate 
>>> (aside from what was automatically migrated by Xcode) can be counted on 
>>> fingers of one or two hands. 
>>> 
>>> I feel that this proposal is reverting something without offering an 
>>> alternative solution.
>> 
>> In what situations do you use Swift 3 private where fileprivate is not an 
>> acceptable replacement?
> 
> In my usage, I very rarely use fileprivate. To back this with numbers, a 
> recent project I developed (i.e. without Xcode's automatic migration of 
> private -> fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 uses 
> of "private”.

Do you have a way to tell how much of the private is effectible fileprivate? 
(top level private usage)



> 
> This is definitely a personal opinion, but I tend to limit access to members 
> as much as possible to discourage/prevent their usage out of the scope they 
> are intended for and to better design API that should be used out of the 
> scope (public/internal). I feel this is a good thing for newcomers to a 
> codebase (and myself coming back to a codebase after a year or two) as 
> Xcode's autocompletion won't offer members that are not supposed to be called 
> out of the scope (scope-private). 
> 
> As I've mentioned this during the discussion, I feel that current state of 
> things encourages huge files (1000+ lines of code) as you can't define 
> "protected" level access and migrate some of the code that implements e.g. 
> accessibility to a different file without potentially exposing internal 
> details to the rest of the module (if the extension in the other file needs 
> access to private details, which is often the case).
> 
> I feel that if there should be a change to the access levels, it should 
> address this as well. The current solution based on reverting the original 
> proposal only unnecessarily exposes implementational details to the rest of 
> the file - at least in my codebase.
> 
>> 
>> Slava
>> 
>>> 
 On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
 > wrote:
 
 
> On Mar 20, 2017, at 4:54 PM, Douglas Gregor  > 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
>  
> 
 -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
 explained my concerns.
 
 
 -- 
 Greg Parker gpar...@apple.com  Runtime 
 Wrangler
 
 
 ___
 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Drew Crawford via swift-evolution]

True indeed… but can we agree that this is just an hypothetic example, and no 
issue that is likely to happen in productive code?
Or is this actually taken from one of the projects you measured?
Here is the expanded edition which is productive.

/**A dummy return value to indicate a method isn't threadsafe.
 Because unused return values produce warnings in Swift, a caller who uses the 
method absentmindedly will have a warning in their code.  This can be 
suppressed with `let _: NotThreadSafe` from the caller. */
struct NotThreadSafe { }

///There are many cache implementations with different performance 
characteristics.
///we model them with a protocol.
protocol CacheImplementation {
    func prune() -> NotThreadSafe
}

///Many components share a single cache, so we expose it as a reference type
class Cache {
    
    init() { preconditionFailure("Provide a constructor to satisfy the 
compiler") }
    private var v: CacheImplementation
    private let lock = DispatchQueue(label: "lock")
    
    
    private func prune() -> NotThreadSafe {
        v.prune()
        return NotThreadSafe()
    }
    ///expose a threadsafe API to callers
    internal func prune() {
        lock.sync {
            //supress the warning, since we have a lock.
            let _: NotThreadSafe = self.prune()
        }
    }
}

extension Cache {
    func pruneAgressively() {
        for _ in 0..<5 {
            self.prune()
        }
    }
}

Note that, in this example, the scoped access keyword actually makes extensions 
*easier*, not harder, to write, because the extension does not need to choose 
between a safe and unsafe version of the method.

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

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

[Shawn Erickson via swift-evolution]

I have a few cases like that in production code with an unthread safe
private function shadows a more public function that applies thread safety
for external callers, etc.

-Shawn

On Tue, Mar 21, 2017 at 9:37 AM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > Fact is, you can replace every occurrence of "private" with
> "fileprivate", and your source would compile as before, whereas fileprivate
> saves us from a "friend"-keyword.
>
> This is certainly a source-breaking change.  Consider:
>
> struct Foo {
>
> fileprivate func foo()->String {return "foo" }
>
> private func foo()->Int {return 2}
>
> }
>
> print("\(Foo().foo())")
>
> Replacing “private” with “fileprivate” here will introduce a compile error.
>
> True indeed… but can we agree that this is just an hypothetic example, and
> no issue that is likely to happen in productive code?
> Or is this actually taken from one of the projects you measured?
> ___
> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[James Berry via swift-evolution]

-1.

While I agree generally that access control in swift is not yet perfect, I feel 
strongly that any further reshaping of access control primitives should wait 
until a submodule design is in place. To do another zag on this issue at this 
point seems preliminary, tweaky, and almost capricious towards our users. The 
access primitives established by SE-0025 added further control. Some may not 
like the naming. But it seems to me that as we contemplate potential further 
shifts down the line with submodules, we’re better off starting from where we 
are today, at a higher level of specificity.


> On Mar 20, 2017, at 4:54 PM, Douglas Gregor  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
>  
> 

> What is your evaluation of the proposal?
The proposal doesn’t to me meet the high hurdles for change in the swift 4 
timeframe. The current situation isn’t broken or horrible. I believe the 
SE-0025 semantics better position us for any access level changes that may be 
required if submodules are adopted.

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

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

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I feel this proposal goes in the wrong direction vis-a-vis expectations for 
access control.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
I’ve closely followed SE-0025 and SE-0159 discussions across the immense 
breadth of space and time they have consumed.

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

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

[Ross O'Brien via swift-evolution]

   - What is your evaluation of the proposal?

In general: against.
Scope-based access is useful and should not be removed.
The fileprivate keyword is long and awkward to say, but unambiguous in
purpose. 'Private' is ambiguous, referring to scope-based access inside a
scope but file-based access outside a scope; this is the more complex term.

I would be in favour of a modified Alternative #3: assigning one keyword to
file-based access and one keyword to scope-based access. However, as
discussed at length during SE-0025, neither level is intuitively the
correct choice to be 'private'.

I would also be in favour of Matthew Johnson's proposal for un-complecting
access from capability - the proposed syntax would address this problem,
though the proposed access-alias feature intended to ensure code is not
broken by its change would not address this problem.


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

A change is required, but not significantly enough to apply the 'solution'
proposed.


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

No.


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

This proposal removes a useful feature.


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

Quick reading.

On Tue, Mar 21, 2017 at 4:12 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Mar 21, 2017, at 10:57 AM, Drew Crawford via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> > I’m not arguing that it is less or more than a majority. I’m just saying
> that we’ve seen a lot of talk against the original change.
>
> This proposal asks us to balance the convenience of one group
> (extension-writers) against the existence of another (scoped-access
> users).  To do that, we need a clear idea of the composition of both groups.
>
> “A lot of talk” is not the evidentiary standard to remove a feature.  It
> was not good enough when we introduced the feature, that required argument
> and clear use-cases.
>
> > By default, I did not mean the syntactic default of the language but the
> access modifier users will use “by default” when trying to restrict
> visibility. In most languages, that keyword is “private” so its valid to
> say that newcomers to the language will “default” to using that one.
>
> Apologies, but I do not understand the argument:
>
>1. A user wants to restrict visibility (e.g. they are dissatisfied
>with “internal”)
>2. The user *chooses* private because of familiarity from another
>language
>3. The user is then surprised that their choice of private indeed
>restricted the visibility, thus achieving their goal?
>
> What language does the user come from in which “private” is file-visible?
> It isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of,
> and it isn’t at all close.
>
> A user who wants a middle-ground visibility would “default” to
> “protected”, “friend”, “partial”, or similar.  After that does not compile,
> they will use google to find a middle-road visibility keyword, for which
> the only candidate is “fileprivate”.  But they will not choose “private”,
> it’s just not a reasonable expectation of what the keyword means to a new
> Swift developer.
>
> The popularity of private “as a default” is simply because many users
> prefer to hide their implementation details as a matter of routine code
> hygiene.  Redefining private in order to thwart their code hygiene goal
> seems extreme.
>
> I agree with several here (as I did in SE-0025) that our access modifiers
> are not well-named.  However, that’s not the proposal in front of us.
>
> > My own statistics in my projects show the contrary. At best, this shows
> how divisive this feature is.
>
> This *may* show that, if contrary statistics were presented, but that
> hasn’t occurred.
>
>
>- In old code, statistics could be biased by the migrator having
>replaced all previous instances of private by fileprivate.
>
> If the migrator migrated code to private, and it *worked* (e.g. did not
> introduce visibility errors) this is not bias, this is a correct use of the
> feature.
>
> > I'm just arguing that the additional scope-based access modifier does
> not provide enough differentiation to be worth that complexity.
>
> The only argument I have seen so far around “complexity” boils down to:
> “some people do not use it”.  But some people *do* use it, and anyway if we
> are going to remove all the features “not enough people” use then we are in
> for a ride.
>
> Swift 3 shipped, so what we are discussing now is yanking a keyword
> without replacement.  There is code written that uses private to enforce
> its threading or security invariants.  There is code written that uses
> private in order to shadow another declaration.   There is code that will
> not compile after 

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

[Colin Barrett via swift-evolution]

On Mon, Mar 20, 2017 at 7:54 PM Douglas Gregor  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?
>
> -1. The proposal does not make a convincing case for why this is a
problem.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Having to write "fileprivate" seems like a pretty minor annoyance.
Especially when compared to having to move any desired private data to a
new file. In my view, the primary purpose of access modifiers below
internal is to keep autocomplete from suggesting implementation details to
clients.
,

>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Given that in other places in Swift, scoping often corresponds with
lexical structure, making "private" an exception seems surprising.
"fileprivate" succinctly communicates this oddity.


>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> I've got a decent amount of experience with access control in Java,
Python, Haskell, and Standard ML.


>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
>  I read the proposal once. (I didn't have time to read the follow-ups
on-list, apologies for any noise.)


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

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

[Matthew Johnson via swift-evolution]

> On Mar 21, 2017, at 10:57 AM, Drew Crawford via swift-evolution 
>  wrote:
> 
> 
> 
>> > I’m not arguing that it is less or more than a majority. I’m just saying 
>> > that we’ve seen a lot of talk against the original change.
> 
> This proposal asks us to balance the convenience of one group 
> (extension-writers) against the existence of another (scoped-access users).  
> To do that, we need a clear idea of the composition of both groups.
> 
> “A lot of talk” is not the evidentiary standard to remove a feature.  It was 
> not good enough when we introduced the feature, that required argument and 
> clear use-cases.
> 
>> > By default, I did not mean the syntactic default of the language but the 
>> > access modifier users will use “by default” when trying to restrict 
>> > visibility. In most languages, that keyword is “private” so its valid to 
>> > say that newcomers to the language will “default” to using that one.
> 
> Apologies, but I do not understand the argument:
> 
> A user wants to restrict visibility (e.g. they are dissatisfied with 
> “internal”)
> The user *chooses* private because of familiarity from another language
> The user is then surprised that their choice of private indeed restricted the 
> visibility, thus achieving their goal?
> What language does the user come from in which “private” is file-visible?  It 
> isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and 
> it isn’t at all close.
> 
> A user who wants a middle-ground visibility would “default” to “protected”, 
> “friend”, “partial”, or similar.  After that does not compile, they will use 
> google to find a middle-road visibility keyword, for which the only candidate 
> is “fileprivate”.  But they will not choose “private”, it’s just not a 
> reasonable expectation of what the keyword means to a new Swift developer.
> 
> The popularity of private “as a default” is simply because many users prefer 
> to hide their implementation details as a matter of routine code hygiene.  
> Redefining private in order to thwart their code hygiene goal seems extreme.
> 
> I agree with several here (as I did in SE-0025) that our access modifiers are 
> not well-named.  However, that’s not the proposal in front of us.
> 
>> > My own statistics in my projects show the contrary. At best, this shows 
>> > how divisive this feature is.
> 
> This *may* show that, if contrary statistics were presented, but that hasn’t 
> occurred.
> 
>> In old code, statistics could be biased by the migrator having replaced all 
>> previous instances of private by fileprivate.
> 
> If the migrator migrated code to private, and it *worked* (e.g. did not 
> introduce visibility errors) this is not bias, this is a correct use of the 
> feature.
> 
>> > I'm just arguing that the additional scope-based access modifier does not 
>> > provide enough differentiation to be worth that complexity.
> 
> The only argument I have seen so far around “complexity” boils down to: “some 
> people do not use it”.  But some people *do* use it, and anyway if we are 
> going to remove all the features “not enough people” use then we are in for a 
> ride.
> 
> Swift 3 shipped, so what we are discussing now is yanking a keyword without 
> replacement.  There is code written that uses private to enforce its 
> threading or security invariants.  There is code written that uses private in 
> order to shadow another declaration.   There is code that will not compile 
> after migration. We need more than a vague fear of complexity generally to 
> throw a brick through all those windows.  That brick will introduce quite a 
> bit of complexity itself.
> 
+1.  On one side we have a vague notion of “complexity” which doesn’t appear to 
amount to much more than a statement of opinion that the granularity isn’t 
useful.  On the other side we have people who find legitimate value in the 
feature for important and clearly articulated purposes.  This seems to me to be 
a solid demonstration that the feature is useful.  

Compiler verification of invariant-preserving encapsulation is important.  It 
is not trivial.  It is not something to be written off lightly because “you’re 
only protecting yourself from yourself”.  People make very similar arguments 
against static typing outside of the Swift community but most of us here see 
value in static types.  Frankly, I’m surprised that so many don’t see more 
value in compiler verified encapsulation.  Is it as important as a robust 
static type system?  No.  But that doesn’t make it unimportant.

>> Concerning the one-class-per-file argument, I would suggest this 
>> counter-argument: when working in large projects, I believe it's a good 
>> thing if the language encourages (forces is too strong a word for my taste) 
>> a one class per file structure, it's good practice.
> 
> The form of the argument is invalid.  Suppose I argued: "it’s a good thing 
> for the language to encourage one definition per 

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

[Drew Crawford via swift-evolution]

> I’m not arguing that it is less or more than a majority. I’m just saying that 
> we’ve seen a lot of talk against the original change.
This proposal asks us to balance the convenience of one group 
(extension-writers) against the existence of another (scoped-access users).  To 
do that, we need a clear idea of the composition of both groups.

“A lot of talk” is not the evidentiary standard to remove a feature.  It was 
not good enough when we introduced the feature, that required argument and 
clear use-cases.

> By default, I did not mean the syntactic default of the language but the 
> access modifier users will use “by default” when trying to restrict 
> visibility. In most languages, that keyword is “private” so its valid to say 
> that newcomers to the language will “default” to using that one.
Apologies, but I do not understand the argument:

A user wants to restrict visibility (e.g. they are dissatisfied with “internal”)
The user *chooses* private because of familiarity from another language
The user is then surprised that their choice of private indeed restricted the 
visibility, thus achieving their goal?
What language does the user come from in which “private” is file-visible?  It 
isn’t Java, C++, or PHP.  C#’s “partial” is the closest I can think of, and it 
isn’t at all close.

A user who wants a middle-ground visibility would “default” to “protected”, 
“friend”, “partial”, or similar.  After that does not compile, they will use 
google to find a middle-road visibility keyword, for which the only candidate 
is “fileprivate”.  But they will not choose “private”, it’s just not a 
reasonable expectation of what the keyword means to a new Swift developer.

The popularity of private “as a default” is simply because many users prefer to 
hide their implementation details as a matter of routine code hygiene.  
Redefining private in order to thwart their code hygiene goal seems extreme.

I agree with several here (as I did in SE-0025) that our access modifiers are 
not well-named.  However, that’s not the proposal in front of us.

> My own statistics in my projects show the contrary. At best, this shows how 
> divisive this feature is.
This *may* show that, if contrary statistics were presented, but that hasn’t 
occurred.

In old code, statistics could be biased by the migrator having replaced all 
previous instances of private by fileprivate.
If the migrator migrated code to private, and it *worked* (e.g. did not 
introduce visibility errors) this is not bias, this is a correct use of the 
feature.

> I'm just arguing that the additional scope-based access modifier does not 
> provide enough differentiation to be worth that complexity.
The only argument I have seen so far around “complexity” boils down to: “some 
people do not use it”.  But some people *do* use it, and anyway if we are going 
to remove all the features “not enough people” use then we are in for a ride.

Swift 3 shipped, so what we are discussing now is yanking a keyword without 
replacement.  There is code written that uses private to enforce its threading 
or security invariants.  There is code written that uses private in order to 
shadow another declaration.   There is code that will not compile after 
migration. We need more than a vague fear of complexity generally to throw a 
brick through all those windows.  That brick will introduce quite a bit of 
complexity itself.

Concerning the one-class-per-file argument, I would suggest this 
counter-argument: when working in large projects, I believe it's a good thing 
if the language encourages (forces is too strong a word for my taste) a one 
class per file structure, it's good practice.

The form of the argument is invalid.  Suppose I argued: "it’s a good thing for 
the language to encourage one definition per class (no extensions), it’s good 
practice.  So we do not need fileprivate.”  That would be very silly (although 
it has already been advanced as a straw-man position elsewhere in this thread). 
The argument that we do not need private because nobody should put multiple 
classes in a file is equally silly. There are reasons to do so, in fact one 
motivation was given in SE-0025:

> Putting related APIs and/or related implementations in the same file helps 
> ensure consistency and reduces the time to find a particular API or 
> implementation. 

These concerns are not resolved by arguments of the form “just don’t do that”.

I empathize with the Swift2 programmer who got through two releases without a 
scoped access modifier and is annoyed by change.  However, removing the feature 
now is more change, not less, so it makes their problem worse, not better.


On March 21, 2017 at 2:17:40 AM, David Hart (da...@hartbit.com) wrote:

Perhaps it was a mistake, but I purposefully did not go into too much detail in 
the proposal because I think this debate is purely a question of philosophy on 
Swift and its language features. I did not want to add un-necessary bloat that 
would 

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

[Drew Crawford via swift-evolution]

On March 21, 2017 at 7:00:32 AM, Tino Heth (2...@gmx.de) wrote:

> If private is really more useful, should we remove fileprivate instead?
We don’t have to remove any access modifier.  They are all useful.

> Fact is, you can replace every occurrence of "private" with "fileprivate", 
> and your source would compile as before, whereas fileprivate saves us from a 
> "friend"-keyword.
This is certainly a source-breaking change.  Consider:

struct Foo {

    fileprivate func foo()->String {return "foo" }

    private func foo()->Int {return 2}   

}

print("\(Foo().foo())")

Replacing “private” with “fileprivate” here will introduce a compile error.





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

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

[Matthew Johnson via swift-evolution]

> On Mar 20, 2017, at 9:33 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > 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
>>  
>> 
> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
> explained my concerns.

I am also -1.  

I think there are two issues to be considered.  One is scoped access itself and 
the other is the names of the access levels.  

I think a reasonable case can be made that changing the meaning of private and 
introducing fileprivate was a mistake.  We probably should have left private 
alone and chosen a new name for scoped access.  There was abundant bikeshedding 
over this at the time, but now we have the benefit of experience.  I believe we 
should have simply called scoped access control `scoped`.  It’s clear that some 
people would still oppose scoped access but I also don’t think we’d be 
revisiting this topic if we hadn’t changed the meaning of `private`.  The 
passionate dislike of the feature seems to me mostly related to stealing the 
`private` keyword.  

I support correcting the naming mistake eventually.  I’m neutral as to whether 
Swift 4 is the right time to do that.  We just introduced a lot of churn in 
Swift 3.  There is still inconsistency in Swift’s access control system as well 
as unmet needs (especially around submodules).  It may be better to leave 
things alone for a release and make the change as part of a larger set of 
changes when access control and submodules are part of a release “theme”.

I am extremely unconvinced that having a scoped access level is actively 
harmful.  It introduces another choice in the language but no individual 
programmers or teams are forced to use the additional flexibility if they don’t 
want to.  It would be very easy for linters to prohibit scoped access if there 
are teams that don’t want to use it.  It is one extra degree of control for new 
programmers to learn but properly taught it helps programmers learn to think 
about encapsulation.  This is a good thing.

On the other hand, I believe removing scoped access is active harmful.  It 
reduces our ability to properly encapsulate mutable state.  For example, I like 
to use scoped access to create small state machine types which are used as part 
of the implementation of another type.  These are usually structs with a 
private enum.  The struct exposes methods which encapsulate state transitions.  
Without scoped access there is no way to encapsulate the state of the state 
machine and force all changes to go through one of the methods on the struct.  
This is just one example of how this feature can be very useful, there are many 
others.  Small helper types like this are very idiomatic in Swift.  It would be 
a big step backward to lose the ability to have proper encapsulation of small 
helper types.

One common argument agains scoped access is that “you’re only protecting 
yourself from yourself”.  I find this to be a bit of a straw man.  It isn’t 
about “protection”.  It is about compiler verified encapsulation.  This 
prevents inadvertent changes that violate the intent of the design.  For 
example, it is not out of the question that without scoped access a new member 
of a large team writes directly to the internal storage of the state machine in 
the above example.  It is also possible that they do so in a way that 
represents an invalid state transition.  The compiler would not catch this 
mistake.  Hopefully it would be caught in a code review but I can imagine it 
getting missed for many different reasons.  On the other hand, with scoped 
access the new team member would be unlikely to prefer changing access control 
to using the intended methods.  If they did change access control this would be 
very likely to be caught in code review.

Access control also provides compiler verified documentation of our code.  This 
facilitates reasoning about our code.  It also communicates design intent from 
the original author to future maintainers.  Removing a tool that many people 
find useful in facilitating reasoning about code is actively harmful.  Teams 
that don’t find this tool useful should use a linter and ban its use on their 
team.  This approach would let those of us who do find this tool useful 
continue to use it.

My observation thus far has been that people seem to be preferring private over 
fileprivate in many cases.  I don’t think this preference is solely about 
typing four less characters.  I think many people really do value the tighter 
encapsulation it provides.

I do think 

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

[Tino Heth via swift-evolution]

> Yes. To cite some evidence, here are codebases I actively maintain:
> 
> | codebase   | private # | 
> fileprivate # | ratio |
> 
> ||---|---|---|
> 
> | "M" (proprietary)  | 486   | 249
>| 2x|
> 
> | "N"(proprietary)   | 179   | 59 
>| 3x|
> 
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH 
>  | 15| 1   
>   | 15x   |
> 
> | atbuild https://github.com/AnarchyTools/atbuild 
> | 54| 5 
> | 11x   |
> 
> So from my chair, not only is the distinction useful, but scoped access 
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
> 
I don't question your numbers, but it's once again a statistic that has to be 
taken with a grain of salt:
The only claim that is backed by the table is that private is used more often 
in your sample — nothing less, but nothing more.
If private is really more useful, should we remove fileprivate instead?
When you do a survey among car owners how often they have used their airbag, 
and how often the cigar lighter socket, I guess the latter number would be much 
higher — but still, I'd rather keep something that will hopefully never be 
used, but could save my life when it does its job.

Fact is, you can replace every occurrence of "private" with "fileprivate", and 
your source would compile as before, whereas fileprivate saves us from a 
"friend"-keyword.

Afaics, the only real argument for private/fileprivate hasn't been brought up 
at all:
Current private is the only level that can be used to demonstrate access 
control in playgrounds — but I doubt this justifies the confusion caused by it.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pranshu Goyal via swift-evolution]

-1

I second Drew Crawford's opinion. Although I agree with some of the
critiques about the current state of access levels in swift, I don't
believe that this would be the right way to proceed.

On 21 March 2017 at 06:56, Drew Crawford via swift-evolution <
swift-evolution@swift.org> wrote:

> I disagree quite strongly with the proposal.
>
> First, the document draws conclusions without apparent supporting
> evidence, e.g.
>
> > Since the release of Swift 3, the access level change of SE–0025 was met
> with dissatisfaction by a substantial proportion of the general Swift
> community. Those changes can be viewed as actively harmful, the new
> requirement for syntax/API changes.
>
>
>- What is “dissatisfaction by a substantial proportion of the general
>Swift community”? How was this measured/determined?
>- What was done to control for the population happy with SE-0025 who
>would e.g. not be likely to take up pitchforks?
>- Who argues these changes are “actively harmful” and where were they
>during SE-0025?
>
> > subtly encourages overuse of scoped access control and discourages the
> more reasonable default
>
>
>- Who claims that scoped access is “overused” and what is their
>argument for doing so?
>- Why is “fileprivate” the “more reasonable default”? In fact neither
>fileprivate **nor** private are default (reasonable or not!). Internal
>is the default. Nor does this proposal suggest we change that. So this
>seems a very strange statement.
>
> > But is that distinction between private and fileprivate actively used by
> the larger community of Swift developers?
>
> Yes. To cite some evidence, here are codebases I actively maintain:
>
> | codebase   | private # |
> fileprivate # | ratio |
>
> ||--
> -|---|---|
>
> | "M" (proprietary)  | 486   | 249
>   | 2x|
>
> | "N"(proprietary)   | 179   | 59
>| 3x|
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1
> | 15x   |
>
> | atbuild https://github.com/AnarchyTools/atbuild| 54| 5
> | 11x   |
>
> So from my chair, not only is the distinction useful, but scoped access
> control (private) is overwhelmingly (2-15x) more useful than fileprivate.
>
> > And if it were used pervasively, would it be worth the cognitive load
> and complexity of keeping two very similar access levels in the language?
> This proposal argues that answer to both questions is no
>
> This proposal does not make any later argument about “cognitive load” or
> “complexity” I can identify.  Did the proposal get truncated?
>
> What is stated (without evidence) is that "it is extremely common to use
> several extensions within a file” and that use of “private” is annoying in
> that case.  I now extend the above table
>
> | codebase   | private # |
> fileprivate # | ratio | # of extensions (>=3 extensions in file) |
>
> ||--
> -|---|---|--
> |
>
> | "M" (proprietary)  | 486   | 249
>   | 2x| 48   |
>
> | "N"(proprietary)   | 179   | 59
>| 3x| 84   |
>
> | NaOH https://code.sealedabstract.com/drewcrawford/NaOH | 15| 1
> | 15x   | 3|
>
> | atbuild https://github.com/AnarchyTools/atbuild| 54| 5
> | 11x   | 6|
>
> in order to demonstrate in my corner of Swift this is not “extremely
> common”, and is actually less popular than language features the proposal
> alleges aren’t used.
>
> My point here is that ***different people in different corners of the
> community program Swift differently and use different styles***.  I can
> definitely empathize with folks like the author who use extensions to group
> functions and are annoyed that their favorite visibility modifier grew four
> extra characters.  Perhaps we can come up with a keyword that is more
> succint.
>
> However, that is no reason to take away features from working codebases.
> A scoped access modifier is perhaps my favorite feature in Swift 3.  Let’s
> not throw stuff away because it adds extra characters to one programming
> style.
>
> Finally, SE-0025 establishes clear motivation for the scoped access
> modifier:
>
> > Currently, the only reliable way to hide implementation details of a
> class is to put the code in a separate file and mark it as private. This is
> not ideal for the following reasons:
>
> > It is not clear whether the 

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

[Brent Royal-Gordon via swift-evolution]

> On Mar 20, 2017, at 8:26 PM, Charles Srstka via swift-evolution 
>  wrote:
> 
> the concern with extensions could be easily solved simply by giving 
> extensions access to private members of the extended type as long as those 
> extensions are in the same module/submodule (or file, if you prefer, but I 
> don’t). This would probably eliminate almost all of the use cases for 
> fileprivate, as well as freeing us from the sometimes clumsy situation where 
> we’re rather artificially forced to use files as a scope, instead enabling us 
> to organize code into files as is appropriate for the project.


I think that many advocates of scoped private misunderstand critics' concerns 
about extensions.

One of the nice things about file-based `private` is that it allows access from 
extensions not only on the same type, but also on *other* types. For example, 
suppose I have a Book type and I want to allow them to be added to bookshelves:

class Bookshelf {
// I'm using file-based private here
private(set) var books: [Book]

func addBook(_ book: Book) {
book.bookshelf = self
books.append(book)
}
}

I also want to have a removal method, but—much like `UIView` and `NSView`'s 
`removeFromSuperivew`—I want that method to be on `Book`, not `Bookshelf`. With 
file-based private, that's no problem—just drop the code in an extension in the 
same file:

extension Book {
func removeFromBookshelf() {
guard let shelf = bookshelf else { return }
shelf.remove(at: shelf.books.index(of: self)!)
bookshelf = nil
}
}

When we talk about file-based private being "better for extensions", we're 
*not*—or at least not necessarily—talking about it being better for the pattern 
of splitting a type into several different extensions to group related code 
together. We're talking about the pattern of splitting a *concern* across 
several different *types* by extending all of them, taking advantage of Swift's 
flexible scoping to encapsulate details even when the type hierarchy doesn't 
match the encapsulation boundaries you want.

So allowing `private` members to be seen by extensions anywhere in a project 
doesn't address this issue; in fact, it actively and aggressively undermines 
it, making it impossible to encapsulate any implementation details at a scope 
smaller than a single type. For myself and others like me, it is the exact 
opposite of what we want.

-- 
Brent Royal-Gordon
Architechies

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

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

[Howard Lovatt via swift-evolution]

The review of SE-0159 "Fix Private Access Levels"

> What is your evaluation of the proposal?

Great idea too fiddly and fussy for my liking. Preferred the original meaning 
of private. 

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

Probably 

> Does this proposal fit well with the feel and direction of Swift?
Yes, keep it simple 

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

Yes Swift 1!

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Have been caught out typing private and then wanting to implement an interfaces 
methods in an extension. 

-- Howard. 

> On 21 Mar 2017, at 10:54 am, Douglas Gregor  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-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charlie Monroe via swift-evolution]

> On Mar 21, 2017, at 8:26 AM, Slava Pestov  wrote:
> 
>> 
>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution 
>> > wrote:
>> 
>> -1 on this as well for similar reasons. Places where I use fileprivate 
>> (aside from what was automatically migrated by Xcode) can be counted on 
>> fingers of one or two hands. 
>> 
>> I feel that this proposal is reverting something without offering an 
>> alternative solution.
> 
> In what situations do you use Swift 3 private where fileprivate is not an 
> acceptable replacement?

In my usage, I very rarely use fileprivate. To back this with numbers, a recent 
project I developed (i.e. without Xcode's automatic migration of private -> 
fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 uses of "private".

This is definitely a personal opinion, but I tend to limit access to members as 
much as possible to discourage/prevent their usage out of the scope they are 
intended for and to better design API that should be used out of the scope 
(public/internal). I feel this is a good thing for newcomers to a codebase (and 
myself coming back to a codebase after a year or two) as Xcode's autocompletion 
won't offer members that are not supposed to be called out of the scope 
(scope-private). 

As I've mentioned this during the discussion, I feel that current state of 
things encourages huge files (1000+ lines of code) as you can't define 
"protected" level access and migrate some of the code that implements e.g. 
accessibility to a different file without potentially exposing internal details 
to the rest of the module (if the extension in the other file needs access to 
private details, which is often the case).

I feel that if there should be a change to the access levels, it should address 
this as well. The current solution based on reverting the original proposal 
only unnecessarily exposes implementational details to the rest of the file - 
at least in my codebase.

> 
> Slava
> 
>> 
>>> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Mar 20, 2017, at 4:54 PM, Douglas Gregor > 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
  
 
>>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
>>> explained my concerns.
>>> 
>>> 
>>> -- 
>>> Greg Parker gpar...@apple.com  Runtime 
>>> Wrangler
>>> 
>>> 
>>> ___
>>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Forgot to cc.

Sent from my iPhone

> On 21 Mar 2017, at 07:43, Goffredo Marocchi  wrote:
> 
> 
> Sent from my iPhone
> 
>> On 21 Mar 2017, at 02:33, Greg Parker via swift-evolution 
>>  wrote:
>> 
>> 
>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor  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
>> 
>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily 
>> explained my concerns.
>> 
> 
> -1 here as well, fully support Drew Crawford's points too. 
> 
> To add my own 2c to it, I would say better time would be spent gathering data 
> on number of bugs, severity, performance and more correlated to the (growing) 
> use of Swift for example rather than just vocally discuss what is Swifty and 
> what is not, talk about safety by default and performance to drive our 
> community decisions without tracking those kpi's (data driven decisions). As 
> much as it could be improved, Mozilla's AreWeFastYet.org's project is a 
> direction we could explore.
> 
> 
>> -- 
>> Greg Parker gpar...@apple.com Runtime Wrangler
>> 
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 21 Mar 2017, at 05:48, Charles Srstka via swift-evolution 
>  wrote:
> 
>> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> Charles Srstka's added comment, while intriguing, poses a problem in 
>> argumentation. One of the points being made above about the major advantage 
>> of new `private` over `fileprivate` is precisely that new `private` is 
>> invisible to extensions. If one "solves" the problem of having to use 
>> `fileprivate` by making `private` visible to extensions, it may well be the 
>> case that `fileprivate` is no longer commonly necessary--but one has also 
>> reverted one of the major arguments in favor of new `private` in the first 
>> place.
> 
> I don’t see making things invisible to extensions to be the benefit of 
> ‘private’ at all—it’s for maintaining encapsulation with embedded types. i.e. 
> things like this:
> 
> class Foo {
>   class Bar {
>   private var baz: String // <— ‘Foo’ doesn’t need to access this
>   }
> }
> 
> This just enforces good programming style.

I cannot believe this proposal is putting scoped access' value into question 
sigh (not you, you are making a point supporting it obviously :)).


> On the other hand, the problem with extensions that people are talking about 
> comes from using extensions to separate sections of a type’s built-in code, 
> mainly around protocol conformances:
> 
> class Foo {
>   private var bar: String
> }
> 
> extension Foo: Baz {
>   func requiredByBaz() {
>   doSomething(with: self.bar) // <— ruh roh
>   }
> }
> 
> The way I look at it, the extension feature was created with the idea of 
> extending someone else’s type in mind, but the community latched onto it as a 
> way to organize the parts of your own type, and Swift 3’s ‘private’ is 
> getting in the way of that. Broadening ‘private’ to reach in-module 
> extensions would solve this issue, and would *also* allow flexibility to, 
> when the code for an extension gets significantly large relative to the rest 
> of the type's code, split that part off into a different file without needing 
> to make your internal state visible to the entire module. Kill two birds with 
> one stone, so to speak.
> 
> 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