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

[Ross O'Brien]

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/fe5dfdde/attachment.html>