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

[Vladimir.S]

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
>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>>
>>
>> Sent from my iPhone
>> On Mar 23, 2017, at 6:41 PM, David Hart <david at hartbit.com
>> <mailto:david at hartbit.com>> 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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>