[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels
Vladimir.S
svabox at gmail.com
Fri Mar 24 09:49:12 CDT 2017
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
> <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>> wrote:
> >
> >> On 24.03.2017 11 <tel:24.03.2017%2011>: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>
> <mailto: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>
> >>> <mailto: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
> <http://rustbyexample.com/mod/visibility.html>
> >>> https://doc.rust-lang.org/book/crates-and-modules.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>
> <mailto:swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>
> >>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >>
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
More information about the swift-evolution
mailing list