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