Thanks for following through on this, Gonzalo! (The two of us talked about this briefly at WWDC.) My idea was a little less clever than yours: just always include the internal members in the main header unless you provide the name of a second header to put them in. (I called this flag -emit-objc-internal-header-path.) That's not quite as flexible, but does remove all the guesswork, at least for generated headers.
I filed a bug to track this work: SR-5221 <https://bugs.swift.org/browse/SR-5221>. Jordan > On Jun 29, 2017, at 06:35, Gonzalo Larralde via swift-dev > <swift-dev@swift.org> wrote: > > I wanted to bring a few points into attention to discuss potential > improvements on Mixed Frameworks support. The current status for Mixed > Frameworks present some challenges, one specifically being how the Swift > compiler generates the ObjC Interface Header. > > At this moment, there's a detection procedure based on the presence of an > entry point definition (either using the main file argument, or > @UIApplicationMain). The ObjC Interface Header writer > (swift/lib/PrintAsObjC/PrintAsObjC.cpp) is using this detection to determine > if the minimum accessibility level to be exported is either `internal` (for > app targets) or `public` (for framework targets). This can be observed here: > https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657 > > <https://github.com/apple/swift/blob/master/lib/FrontendTool/FrontendTool.cpp#L652-L657> > > The result of this is a difference on how default visibility is exposed to > ObjC code in the same compilation scope. > > Having this initial piece of code: > > ``` > public class Test: NSObject { > public foo() {} > func bar() {} > } > ``` > > results on the following Interface Header for Main App targets > > <target-name>-swift.h > ``` > @interface Test : NSObject > - (void)foo; > - (void)bar; > @end > ``` > > and the following for Frameworks > > <target-name>-swift.h > ``` > @interface Test : NSObject > - (void)foo; > @end > ``` > > This is clearly correct for the publicly visible interface of the framework, > but not quite the expected result for the ObjC code compiled in the same > target. In that scenario it would make more sense to me that all the > `internal` methods are visible. > > A potential solution for this problem is to generate two Interface Headers, > one that exports all the `public` and `open` entities and members, and an > additional header exposing internal entities and declaring categories to > public entities and exposing internal members. > > Something like: > > <target-name>-swift-internal.h > ``` > @interface Test (InternalMembers) > - (void)bar; > @end > ``` > > After that it'll be Xcode's responsability to create both files, and mark > them as Public and Project in the Headers Build Phase. > > An initial implementation that I think would make sense in case this solution > is accepted could be modifying the signature of `swift::printAsObjC` to > require the list of access levels to export as a bitmask instead of just > getting the minimum. That will enable the exporter to create the following > set of files: > > * Internal, Public, Open > <target-name>-swift.h for app targets > * Public, Open > <target-name>-swift.h for framework targets > * Internal > <target-name>-swift-internal.h for the internal entities and > members on framework targets. > > To make this happen a new argument needs to be passed to the compiler call. > When it's not passed the default behaviour would remain the same, but when it > is the behaviour needs to be explicitly defined. One option is to just get > the explicit list of access levels to export (something like > `-export=internal,public,open`) or export levels to be defined (0 for app > targets, 1 for public framework targets and 2 for the internal header > framework targets for example) > > I hope this feature proposal is complete enough to properly define the scope > and discuss the viability of a possible solution. Otherwise please let me > know. > > Thanks. > > -- > Slds, > > Gonzalo. > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
