> On Jun 22, 2016, at 7:59 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > >>> >>> I would really like to see submodules, but I think there would still be >>> valid uses for `fileprivate` even with them. But of course we would need >>> to know the details of submodules to have a good discussion about that so >>> it’s a topic for the future. :) >> >> I wonder what became of this: >> https://github.com/apple/swift/blob/master/docs/Modules.rst#id18 > > As the author of that document, it became clear (or maybe “it became murky”) > that everyone wants different things from submodules, both for compiling > their own targets and for importing other people’s targets.
Surveying the larger github swift projects it is clear that people currently struggle to structure code when compared with c++, java, c# or even scala. It may just be that many come directly from objc. It is particularly visible on the server side libs out there where a module sometimes mean a class and a protocol... Without getting sidetracked too much it should be possible to devise a limited improvement on the current situation, maybe even outside of this community to avoid some of the endless meandering i have seen on 'hot' topics. > I’d almost suggest avoiding the word if you want to propose any of myriad > features related to them: > > - importing a subset of APIs > - having APIs not imported by default with the top-level module > - C++ namespacing within a module > - C++ namespacing within another module > - breaking up compilation units (i.e. not compiling the entire module as one > unit) > - adding another access level between internal and fileprivate. > - adding another access level between fileprivate and private. > - something else? > > (still catching up on the main thread, but I think Robert and Matthew are > both right: we need to explicitly amend the proposal, and the behavior we > want is fairly obvious) > > Jordan > _______________________________________________ > 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
