[swift-evolution] [Proposal][Discussion] Modular Swift

[Robert Widmann]

Let’s use some code to illustrate things.  

// FooUtilities.swift
//
// -module-name=Foo
// module Foo {
// Defines Foo.Utilities
module Utilities {
  internal func visibleInThisSubmodule() {}
}
//}

// FooUtilities+MoreUtilities.swift
extension Foo.Utilities {
  private func privateHelper() {
    visibleInThisSubmodule()
  }
}



> On Feb 21, 2017, at 10:31 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> On Tue, Feb 21, 2017 at 9:29 PM, Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> wrote:
> Once again, internal is your keyword.  An extension allows you to “open and expand” the module boundary here, which is exactly what you want here - to extend this module across file boundaries without showing your cards to an external consumer of your framework. 
> 
> Sorry, I don't understand. Does your design support the use case below? I don't think it does. Are you replying that supporting the use case below is not a goal of your proposal? If so, please just say so.
> 
> 
>> On Feb 21, 2017, at 10:26 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Sorry, been replying to multiple sub-threads today.
>> 
>> 
>> For bar(), because you wish to be able to
>> 
>> 1) Not export it across the outermost module boundary
>> 2) But still use it internally
>> 
>> Internal access is required.  Any higher and you would export (violating 1), any lower and you wouldn’t be able to internally import (violating 2).
>> 
>> For baz(), because you wish to be able to
>> 
>> 1) Not export it across the outermost module boundary,
>> 2) Or even your own internal submodule boundary
>>  
>> 3) But still use it within the same submodule, across different file boundaries: this is the feature that many people have stated they want to emerge out of a submodule design.
>> 
>> Private or fileprivate suffices depending on the scoping you wish for it to have within the file/interface it’s a part of relative to the other APIs in the submodule.
>> 
>> > On Feb 21, 2017, at 10:04 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>> >
>> > I specified two different behaviors for `bar()` and `baz()`. I see now that you describe `internal` as having the behavior I want for `bar()`. Is there a way I can get the behavior I want for `baz()`?
>> >
>> > --
>> > Brent Royal-Gordon
>> > Sent from my iPhone
>> >
>> > On Feb 21, 2017, at 6:51 PM, Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> wrote:
>> >
>> >>> What access modifiers do I put on `bar()` and `baz()` so that `MyMod` can access `bar()` but not `baz()`, and code outside `MyMod` can access neither `bar()` nor `baz()`?
>> >>>
>> >>
>> >> internal
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170221/65a4bf6b/attachment.html>