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

[Robert Hedin]

This would address my concerns.

rob


On Fri, Mar 24, 2017 at 10:27 AM, Ross O'Brien via swift-evolution <
swift-evolution at 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 at 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 at 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
>> >>> <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
>> >>
>> > _______________________________________________
>> > swift-evolution mailing list
>> > 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
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
*Robert **Hedin  *|Dir Software Engineering
*w:* 770-226-2650      *e:* robert.hedin at weather.com
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps> <http://weather.com/apps>
<http://weather.com/apps>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/e6618008/attachment.html>