I checked this out when I was making my lists. It's a very simple solution, but I feel like "internal (module-scoped) method on a public class" is a common enough use case that we wouldn't want to rule it out, or force the user to write a separate extension.
Jordan > On Mar 29, 2016, at 8:12 , Thorsten Seitz via swift-evolution > <[email protected]> wrote: > > FWIW, Ceylon uses only a lexical access level like in the proposal (as I > understood it): > > program elements which are visible only inside the scope in which they are > defined, and > program elements which are visible wherever the thing they belong to (a type, > package, or module) is visible. > > In Ceylon this level is called "shared". > > -Thorsten > > Am 29.03.2016 um 16:24 schrieb Paul Ossenbruggen via swift-evolution > <[email protected] <mailto:[email protected]>>: > >> 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] >>> <mailto:[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] <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
