Thanks for the suggestion, I will give it some thought and may others will do the same.
My issue with this topic is that I feel there is a lot of emotion but not yet a clear agreed best path forward. We should also think about design and implementation opportunity cost, what are we not addressing/focusing on/designing by focusing on arguing loudly about reverting a change set? Sent from my iPhone > On 20 Feb 2017, at 09:15, Rien <r...@balancingrock.nl> wrote: > > > > > >> On 20 Feb 2017, at 09:39, Goffredo Marocchi via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Please, almost anything but going back to the horrible Objective-C pattern >> of private headers (that end up included on in the implementation files) :/. > > Why not a best of both worlds? > > Everything is open inside the project unless marked private (in the swift 2 > sense, i.e. fileprivate) > > If a project/module exports a library, the same applies, unless there is a > “library access level control file”. > > If a "library access level control file” is present, all external access > defaults to private unless disclosed in the “library access level control > file”. > > With proper IDE support, creating a "library access level control file” would > require only minimal effort. > > This would allow cleaner source code as you do not have to specify every > access level all the time, reduces cognitive load during programming and > debugging, fits nicely in the progressive disclosure strategy, creates a more > readable interface for API users etc etc. > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Balancingrock > Project: http://swiftfire.nl > >> >> Seriously, that was always my issue with that blog post, assuming that the >> Objective-C way of dealing with this issue was something worth moving >> forward and not a path to massively improve upon or to avoid. >> >> Sent from my iPhone >> >>> On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> A third point (which is a bit more complex/convoluted) is that fileprivate >>>> remained an essential language feature because it allows implementation in >>>> extensions, and allows a simple “friend”-like feature where types that >>>> need access to implementation details due to higher coupling could be >>>> bundled into the same file. Outside of a desire of a scoped ‘private’ >>>> simply to match the behavior of certain other languages, private is used >>>> to hide implementation details from other parts of a file, while file >>>> private exposes them within the file. >>>> >>>> There is a potential that file-private can lead to an explosion of >>>> complexity due to a large amount of “friendly types” being bundled into >>>> the same file. In that sense, ‘private’ was wrong because it was adding >>>> complexity at the file level, when really a new access level would >>>> possibly have been more productive to define at the at the >>>> small-group-of-files level - either via a friend access level or >>>> submodules. We still have the potential of unmanageable files due to >>>> friend types, but any additional access levels to aid with this problem >>>> would have to be weighed against a now significantly more complex access >>>> model including file and scoped private. In that sense, the inclusion of >>>> scoped private may indeed be harmful in that it increases the challenge of >>>> much more useful access levels being added to the language. >>> >>> This is the core of what I have been saying. If we don’t address this need >>> of “friendly types” in a swift-y way, we will have to keep coming back to >>> the drawing board (either for “friend” or “protected” or “submodules”). I >>> really like swift 2 private, but it did cause long files because all of the >>> extensions and friends had to be stuck in the same file. What we are really >>> missing is something that has the connotation similar to private, but >>> allows access where needed. >>> >>> I agree with most of what was said in this blog post from the swift devs: >>> https://developer.apple.com/swift/blog/?id=11 >>> >>> The main exception is that I disagree that ‘internal’ maps to the ObjC case >>> where a second header was used (it doesn’t, and that is what is causing all >>> of this trouble). Because internal is the default, it feels much too easy >>> to accidentally use parts of a type which should only be used by >>> extensions/subclasses/friend types. Remember, in an app (as opposed to a >>> framework), internal is basically equivalent to public. With the second >>> header, users of the contents of that header had to explicitly include it, >>> which meant there was no chance of accidental use. >>> >>> What we need is something which maps to that second header case while still >>> keeping everything conceptually simple and swift-y. >>> >>> Thanks, >>> Jon >>> >>> >>> _______________________________________________ >>> 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
