A new type is implicitly internal to a module. Implicitly specifying it as 'external' is just plain confusing.
On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > I know this is kind of winding down, and there seems to be a kind of > begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), > but I still really don’t like it so I’m going to toss out my current > favorite configuration and try to stop caring and defer to the core team to > make an executive decision so we can all move on with our lives. :P > > public - unchanged, visible “everywhere" > external - visible outside of the file (module, the default) > internal - visible only within the file > private - visible only within the scope > > I really like the existing private and I use it a lot to build collections > of small classes and structs that work together rather than a large > class/struct that tries to “be everything”. In those scenarios, traditional > OO private would be too restrictive and even a “protected” access type > wouldn’t work because I’m trying to avoid building inheritance hierarchies. > I really need something like “friend” (ugly) or the, imo, much more elegant > file-scoped access and if that one is renamed “fileprivate” I’ll be really > sad seeing such an ugly label all over the place. I’d go so far as to > suggest that an ugly name for this access level would actively discourage > its use and while some might have that as a goal, to me that would > encourage the creation of larger “do everything” classes instead of > clusters of smaller classes and structs and protocols. > > l8r > Sean > > > On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution < > swift-evolution@swift.org> wrote: > > > >> I’ve seen a number of concerns on this list about moduleprivate, and > how it penalizes folks who want to explicitly write their access control. > I’ve come to think that there is yes-another possible path forward here > (which I haven’t seen mentioned so far): > >> > >> public > >> internal > >> fileprivate > >> private > >> > >> The advantages, as I see them are: > >> 1) We keep public and private meaning the “right” and “obvious” things. > >> 2) The declmodifiers “read” correctly. > >> 3) Compared to Swift 2, there is almost no change. The only thing that > changes is that some uses of Swift 2 “private” will be migrated to > “fileprivate”, which makes the intent of the code much more clear. > >> 4) fileprivate is the unusual and > not-really-precedented-in-other-languages modifier, and it would still be > “googable”. > >> 5) The addresses the “excessively long” declmodifier problem that > several people are concerned with. > >> 6) Support for named submodules could be “dropped in” by parameterizing > “internal”. > >> > >> Thoughts? > > > > +1 > > > > Following on from my experience with Delphi adding "strict private" for > "OO private" members of classes, I would totally agree with your > proposition. > > > > Having to use Delphi's "strict private" never really felt right to those > of us who were brought up on the OO concept of private, and having > "private" mean file scope simply encouraged very bad, large, files with > lots of classes; especially for those who were new to programming. > > > > This proposal means that folks coming from other OO languages will > instantly understand "private"; "fileprivate" does what it says on the tin. > > > > To my mind, the only extra scope that might be useful is the OO concept > of "protected" on a class, but I would like to see a discussion purely > centred on the effect of more protocols and less class inheritance, with > its attendant impact on whether protected could also suit extending > (otherwise private) scope to extensions. > > > > In recent experiments of adapting the GOF Design Patterns to Swift, I > have found using protocols and extensions to greatly reduce the need for > class inheritance, if not removing the need for classes at all in favour of > structs. > > > > Joanna > > > > -- > > Joanna Carter > > Carter Consulting > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org > > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution