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
<[email protected] <mailto:[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] <mailto:[email protected]>> 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
>>> <[email protected] <mailto:[email protected]>
<mailto:[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]>
>>> <mailto:[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
<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
>>> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
<https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
