[swift-users] Discrepancy between sharing internal Swift symbols with Obj-C when in an app vs a framework target

[Jordan Rose]

We don't currently have a way to generate two headers, one to be used internally and one externally. For methods and properties on existing types, it's safe to write a category manually to be included in your .m files, but classes and protocols don't really have a good answer.

This is very similar to another existing problem, that you can't import implementation-detail things into Swift without making them public. However, that problem still needs a lot of design, whereas this one is essentially as simple as "generate two headers". (It's not quite that easy because you need one to import the other rather than having them be independent, but it's still a problem where it's known that the solution will work.)

"Simple" or "easy" does not necessarily mean "quick to implement", though, so we have to balance this against other improvements.

Best,
Jordan


> On Jun 4, 2016, at 13:00, Daniel Dunbar via swift-users <swift-users at swift.org> wrote:
> 
> Unfortunately, this is a limitation of the current model for mixed Obj-C and Swift targets. The Swift code is compiled and optimized as a single module, and the only supported external entry points that result from that are the public API, which is then exposed as the "<module>-Swift.h" header file.
> 
> However, this limitation applies to application targets as well, so I'm not sure I understand yet what the blocker is w.r.t. your migration. Can you explain more?
> 
> - Daniel
> 
>> On Jun 4, 2016, at 11:29 AM, Kevin Lundberg via swift-users <swift-users at swift.org> wrote:
>> 
>> The former case is what I'm concerned with. I agree that code external to the framework should only see public symbols. However objc code inside the same framework as the swift code in question should ideally be able to see internal swift symbols as well, as they are within the same module.
>> 
>> --
>> Kevin Lundberg
>> 
>> On Jun 4, 2016, at 2:48 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>>> I ran into a major hurdle this week that basically stopped my work in
>>>> its tracks. I've been working on moving a large codebase from an iOS app
>>>> target to a framework target, since we have the same code in multiple
>>>> app targets and it is problematic to have to remember to add new code to
>>>> every single app target when they can all just share a framework.
>>> 
>>> To be clear: Are you having trouble making the Objective-C and Swift inside your framework talk to each other, or the Objective-C outside your framework talk to the Swift inside your framework?
>>> 
>>> If it's the latter, then I agree with Jens that this is "works as intended", and you're just going to have to spend some time pasting `public` into your code in a lot of places. But if you're being forced to make Swift APIs public so you can use them from Objective-C *inside* the framework, that might be something worth talking about.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160606/cce1ddf5/attachment.html>