[swift-evolution] SE-0025: Scoped Access Level, next steps

[Ross O'Brien]

That depends how you define 'namespace'. A module is a set of files. Is a
namespace a set of files, a subset of the module's set?

If yes, namespace fits in with the hierarchy: 'public', 'module private',
'namespace private', 'file private', 'scope private'. Easy.

If no, then I'm guessing it means that some parts of a file are in a
namespace and some aren't. That's orthogonal to the scope-based hierarchy.
That causes explosions of keywords - now you have symbols visible only
within one file, and only within the namespace region of it. And other
symbols visible within the namespace regions of other files, but not
outside the namespace in the file where it's declared. And others visible
within a file, invisible to regions of the namespace outside that file. Did
we just generate 'namespace internal', 'file internal' and 'namespace file
internal'? Which of these is 'internal'?

On Tue, Mar 29, 2016 at 5:19 PM, Paul Ossenbruggen <possen at gmail.com> wrote:

> What does that even mean fileprivate in a namespace? Does it become
> exposed outside the namespace? Not so private anymore. Now we have this
> namespaceprivate thing too? Since a namespace could span multiple files.
> Getting very confusing quickly.
>
>  If it is just "internal", it means within the scope of the namespace.  If
> there is no namespace internal means internal to the file. I don't want to
> design  namespaces here though, just keep a path to context helping with it
> and not have to redo all the access levels down the road.
>
> These levels would stay consistent within the scope in which they are
> defined.
>
> - Paul
>
> Sent from my iPhone
>
> On Mar 29, 2016, at 8:13 AM, Ross O'Brien <narrativium+swift at gmail.com>
> wrote:
>
> If 'knowing from the context that it only applies to a certain scope' is
> really that helpful, then let's make it as simple as we can:
> 'firstprivate', 'secondprivate', 'thirdprivate', 'fourthprivate'. That's an
> easily extensible system: if we need a new level, we add 'fifthprivate'.
> Then we re-learn the context of each one.
>
> I don't see that as advantageous.
>
> This is the advantage of 'moduleprivate' and 'fileprivate' is to me: the
> definitions of 'module' and 'file' will not change. I know where the
> visibility of these symbols ends, just by reading it. I don't need to
> consult the new Swift X contextual scale. I don't have to relearn it if we
> add a new level. If we add 'namespaceprivate' then it is immediately clear
> that any symbol so marked is visible within a namespace and if it isn't
> immediately clear then my first documentation search will be for 'Swift
> namespace' and not something like 'Swift restricted' followed by 'Swift
> namespace'. We bake this objective information into the keyword itself,
> information which is simply not present in terms like 'private' or 'local'
> or 'secret', and we become more confident knowing that the definition of
> 'file' won't change between versions, and that makes our code easier to
> maintain.
>
> I have enough new things to learn as Swift evolves. Disambiguating
> 'typealias' into 'typealias' and 'associatedtype' was a new thing to learn
> which improved Swift's clarity. Renaming 'private' as 'internal' does not
> improve clarity.
>
> On Tue, Mar 29, 2016 at 3:24 PM, Paul Ossenbruggen <possen at gmail.com>
> wrote:
>
>> Just as context is used for variable names does not need a specific
>> scoping specifier every time one is declared.  You know from the context in
>> which it is used that it only applies to a certain scope.
>>
>> I would hope that if namespaces are added we would not have
>> namespaceprivate etc The keywords would explode and become quite
>> confusing..Instead if it is in a namespace you would use internal or
>> external and the scope changes to the namespace rather than the file but as
>> I said this is beyond the intent of this proposal.
>>
>> On Mar 29, 2016, at 7:04 AM, Ross O'Brien <narrativium+swift at gmail.com>
>> wrote:
>>
>> How is flexibility desirable?
>>
>> Why is it important to me, if I decide that a given class should only be
>> visible at 'internal' scope, that the meaning of 'internal' should be
>> subject to change in future versions of Swift? 'Once you know its meaning'
>> should mean once!
>>
>> Right now, I use the word 'private' when I want code to be only visible
>> within a file. When I migrate a project to Swift 3, an automatic migrator
>> may not be able to tell whether a given private property should now be
>> scope-private or file-private. Perhaps we can assume that anything private
>> referred to in more than one scope should be file-private and everything
>> remaining should be scope-private, but I think it would still be wise to
>> manually review the changes. Using 'internal' to replace 'private' may make
>> that process even more complicated... but okay, it's a one-time cost.
>>
>> I don't see the advantage in knowing that adding another visibility level
>> in future will require another intensive review. I'd prefer it if a keyword
>> was explicit about its meaning. Migration can then be straightforward:
>> everything 'private' now can become 'file-private', and if I want to reduce
>> the visibility of anything to scope-private then I can do so manually. If
>> we add an even more private level in future then the code doesn't break
>> just because 'private' was too subjective in its meaning.
>>
>>
>>
>>
>>
>> On Tue, Mar 29, 2016 at 2:23 PM, Paul Ossenbruggen via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> public (unchanged)
>>> external (module access)
>>> internal (file access)
>>> private (scoped access)
>>>
>>>
>>> This seems logical and something I could live with, but how is it better
>>> than moduleprivate and fileprivate? Also, internal has contradictory prior
>>> art in C# and Swift 2 (not that it stops us).
>>>
>>> And I see the length of moduleprivate and fileprivate as a feature, and
>>> external/internal lacks it.
>>>
>>>
>>> It is better than moduleprivate and fileprivate in that it is a single
>>> word which is easier to to read and there is less typing. Less typing even
>>> with autocomplete is a benefit. Once you know its meaning, that both are
>>> relative to file access, you won’t have to look it up. Also, just noticed
>>> this, when I type multiword keywords in an email program or chat program
>>> autocorrect butts in. This is of practical value because much work is done
>>> in chat and email programs.
>>>
>>> Simpler is better if it sufficiently conveys the meaning and it does in
>>> this case. The expectation with most keywords are that they be single
>>> words, especially ones that are used the most.
>>>
>>> There is a nice symmetry to internal/external and public/private.
>>>
>>> If external/internal refer to the file, then we don’t need the multiword
>>> descriptive versions.  Also, if we decide later that scoping to namespaces
>>> is desired these same already reserved keywords give us more flexibility
>>> than the more specific keywords would allow. Internal/external could refer
>>> to the namespace scope rather than the file scope if it is inside a
>>> namespace (this is beyond the scope of the proposal but trying to think
>>> ahead). By not explicitly stating the scope you gain flexibility
>>>
>>> - Paul
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160329/7a5440c3/attachment.html>