This would address my concerns. rob
On Fri, Mar 24, 2017 at 10:27 AM, Ross O'Brien via swift-evolution < [email protected]> 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 < > [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 > > -- *Robert **Hedin *|Dir Software Engineering *w:* 770-226-2650 *e:* [email protected] <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>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
