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
