I believe we will need another non-type access level if frameworks are ever divided into submodules.
-DW > On Mar 30, 2016, at 7:13 AM, Ilya Belenkiy via swift-evolution > <[email protected]> wrote: > > I am not sure if we will ever get another access level. If we do, great, but > given how long this discussion has been already, I am not counting on it :-) > > Most likely, if we get more, it will be possible to describe it with a simple > word, or a combination of words or with some common abbreviations, so I am > not worried about extensibility. I think that the names in the proposal are > very consistent with Swift as it is today and will serve us well. They are > also completely unambiguous and don't depend on the reading context, so if we > come up with other ways to label access levels, it should still be possible > to either use these names for backward compatibility or migrate them > automatically to new names without any difference in semantics. > > We also needed to pick something. I waited for about a week to get > everybody's vote, and I think that I picked a compromise that we can all be > at least ok with. (I also originally wanted short single word names). I think > we should close the naming thread at this point. > On Wed, Mar 30, 2016 at 5:26 AM Matthew Judge <[email protected] > <mailto:[email protected]>> wrote: > > > On Mar 29, 2016, at 20:47, Brent Royal-Gordon via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > >> If Scala style access modifiers were adopted for Swift then a > >> private(file) modifier would also be necessary to give the current private > >> functionality. > > > > I could imagine having these options: > > > > public // visible to all everyone > > private(scope-name, scope-name, …) // visible to specified scopes > > (plus current scope) > > private // visible only to current scope > > > > Allowing multiple "scope-name"s is a lot of flexibility and power, but not > sure it's useful/worthwhile. > > For the current discussion, I would think "scope-name" should be limited to > an enclosing scope only. So you can say "private(Outer)" from an Inner class > or "private(#file)" from within a class, but not "private(ClassA)" from > within ClassB. > > (This would also solve the ambiguity of how to reference the main ClassA or a > specific extension to ClassA... "private(ClassA)" can only refer to whichever > scope of ClassA you are currently in.) > > > scope-name could perhaps be: > > > > * A type name (or Self, which would mimic C++-style private, or perhaps > > even C++-style protected depending on how we treat inheritance) > > But, this is getting into type-based access which is beyond the scope of > SE-0025 right? > > > * A module name (or #module for the current module) > > * A file name string (or #file for the current file) > > > > And then the default would simply be `private(#module)`. > > > > Alternatively, the parameterized level could be given a different name, > > like `internal` or `shared`. If that were the case, then `#module` might > > simply be the default. > > > > -- > > Brent Royal-Gordon > > Architechies > > > > _______________________________________________ > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
