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

[Xiaodi Wu]

On Tue, Feb 21, 2017 at 9:34 PM, Robert Widmann <devteam.codafi at gmail.com>
wrote:

> 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()
>   }
> }
>

Either I'm entirely misunderstanding what you're trying to illustrate, or
this is totally unresponsive to Brent's question. In either case, I'll let
Brent ask his own question from here.


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>
> 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> wrote:
>>
>> On Tue, Feb 21, 2017 at 9:08 PM, Robert Widmann via swift-evolution <
>> 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> 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>
>>> 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
>>> 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/8f5f7f10/attachment.html>