> On Jun 22, 2016, at 3:14 PM, Jordan Rose <[email protected]> wrote:
>
>>
>> On Jun 22, 2016, at 13:05, Matthew Johnson <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Jun 22, 2016, at 12:59 PM, Jordan Rose <[email protected]
>>> <mailto:[email protected]>> 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
>>>> <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. I’d
>>> almost suggest avoiding the word if you want to propose any of myriad
>>> features related to them:
>>
>> Interesting. The reason I like the idea of submodules is because I think
>> they could accomplish several of these goals with a single feature in a more
>> elegant manner and without introducing nearly as much complexity as would
>> likely be present with independent features.
>>
>>>
>>> - importing a subset of APIs
>>> - having APIs not imported by default with the top-level module
>>
>> Aren’t these kind of duals of each other (subsets of APIs being submodules,
>> possibly with some APIs directly in the root module)?
>
> Most Clang submodules allow importing a subset of APIs, but still import
> everything by default with the top-level module. Explicit submodules are the
> exception rather than the common case.
That makes sense.
>
>
>>
>>> - C++ namespacing within a module
>>
>> This is perhaps the most straightforward goal, but I believe it would be
>> better served by a more robust submodule feature rather than being a limited
>> namespace feature (for example, integrating with the subset import mentioned
>> above).
>>
>>> - C++ namespacing within another module
>>
>> Can you elaborate? Do you mean namespaces that are “open to extension” in
>> any module similar to how we can extend types from imported modules, provide
>> retroactive conformances, etc? If that is what you mean I am not at all
>> convinced there is value in this.
>
> import Foo
> Foo.Bar.baz()
>
> It’s not obvious that a namespace within the main module (the module
> currently being compiled) shouldn’t be flattened when the module is
> published—say, if things are only broken up for compilation time purposes.
> Alternately, it’s not obvious that the namespaces within a module match up to
> the units you want to be able to import as submodules.
This is interesting. I suppose internal namespaces that are flattened could
make sense in very large modules. That is something I hadn’t considered. It
feels orthogonal to submodules to me but is certainly related.
>
>
>>
>>> - breaking up compilation units (i.e. not compiling the entire module as
>>> one unit)
>>
>> This feels like it could be a build setting independent of submodules. For
>> example, if you want WMO to span all submodules you wouldn’t necessarily
>> want this, but if WMO isn’t important maybe you do.
>
> People mostly want this for compile time.
Right. But the ability to make a tradeoff between compile time and runtime
performance feels more like a build setting of some kind (to me) rather than
semantics of a language feature.
>
>>
>>> - adding another access level between internal and fileprivate.
>>
>> This obviously makes sense in the context of a submodule (or namespace)
>> feature, but feels (to me) like it would be awkward as an independent
>> feature.
>>
>>> - adding another access level between fileprivate and private.
>>
>> Are you thinking of a file that contains scopes from different submodules?
>> I’m trying to think of how this would do something that the new `private`
>> wouldn’t already be able to do.
>
> A few people would prefer to break a file up into (disjoint) groups rather
> than have groupings across files. I personally think this would not be a good
> feature, but it goes on the list.
Yes, but I don’t understand why the new `private` wouldn’t accomplish the goal
access control in this context. Here’s a strawman example:
submodule Foo {
private func bar() { … }
// bar is only visible inside the scope introduced by `submodule Foo`
}
What do you have in mind that wouldn’t be possible given some kind of syntax
like that?
>
>
>>
>>> - something else?
>>
>> The big ones IMO are API subsets, namespaces, and encapsulation (access
>> control) which feel like they fit very nicely together as a single elegant
>> submodule feature.
>
> “80% of the users only need 20% of the features, but everybody uses a
> different 20%”.
>
> I’d be happy to have one feature that serves multiple purposes; however, in
> any such proposal I don’t want to take any behavior as obvious, because in
> the last three years someone has at one point asked for the opposite. :-)
Sure. You’ve certainly had a lot more experience exploring and discussing this
area than I have! :)
I still think it would be worthwhile to have a community discussion on the
topic (at the right time of course) and see if we can’t find a balance that is
workable.
Matthew
>
> Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
