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 <[email protected]> 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 > <[email protected] <mailto:[email protected]>> wrote: > >> On Mar 29, 2016, at 12:32 AM, Andrey Tarantsov via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 > [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
