Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-5221] Second generated header for the 'internal' parts of framework targets #47797

Open
belkadan opened this issue Jun 14, 2017 · 8 comments
Assignees
Labels
compiler The Swift compiler in itself feature A feature request or implementation objective-c interop Feature: Interoperability with Objective-C PrintAsClang Area → compiler: The PrintAsClang library

Comments

@belkadan
Copy link
Contributor

Previous ID SR-5221
Radar rdar://problem/59333073
Original Reporter @belkadan
Type New Feature
Additional Detail from JIRA
Votes 1
Component/s Compiler
Labels New Feature, PrintAsObjC
Assignee @nkcsgexi
Priority Medium

md5: 9ba074083669e26a8ed45ebe1759e489

Issue Description:

To improve mixed Swift/Objective-C frameworks, there should be a way to generate a header for the internal parts of a Swift framework that are also @objc. This would act like a "project" header in Xcode that does not get copied into the build products.

This hasn't been implemented in the past mainly because it requires splitting the internal members of a public class out to a category, but support for "delaying" members got added last year in PR 4155 anyway. This would just be another form of that.

Implementing this would involve something like the following:

  • A new -emit-objc-internal-header-path command-line option.

  • Rather than skipping over internal declarations in PrintAsObjC, adding them to a list much like the delayedMembers list today.

  • Print all those declarations to a separate buffer, with a separate imports list.

  • Write all that to a new header that imports <MyModule/MyModule-Swift.h>.

There are then Xcode-side changes that need to happen to make this a fully-supported feature, but this would be good enough to use it with a toolchain!

@belkadan
Copy link
Contributor Author

Not quite a StarterBug, but not out of the question for an external contributor who's already done a few StarterBugs.

@beccadax
Copy link
Contributor

beccadax commented Apr 9, 2020

The PR in #29751 would address this, but it's not clear when we'll land it.

@swift-ci
Copy link
Collaborator

Comment by Brian Boyle (JIRA)

Just wanted to check if there is a chance this feature might be addressed in the near future?

I notice the PR linked above was closed without being merged.

Currently facing this issue of private Swift code in an XCFramework being publicly exposed because functions need to be marked private in order to be available to Objective-c code.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@jaichaudhry
Copy link

jaichaudhry commented Jan 19, 2023

Hello, do we have any updates on this? @beccadax . We have a similar use case for our SDK framework and its getting hard to interoperate inside our framework. The only option is to fully migrate to swift, but unfortunately that won't be possible for us at this stage.

@AnthonyLatsis AnthonyLatsis added objective-c interop Feature: Interoperability with Objective-C feature A feature request or implementation and removed new feature labels Jan 19, 2023
@bc-lee
Copy link

bc-lee commented Feb 4, 2023

Some projects already use the internal class/methods of the Swift framework in their Objective-C code. Not sure if this behavior is expected.

https://forums.swift.org/t/is-it-possible-to-access-internal-methods-of-swift-framework-from-objective-c/62951

@bc-lee
Copy link

bc-lee commented Feb 5, 2023

I discovered that passing -application-extension exposes internally visible swift classes/methods in Objective-C headers. However, it would be much better if visibility could be controlled with a compiler flag other than that.

@juraskrlec
Copy link

Hi, just to see if this feature is still considered? It would be really helpful to get this as a feature for frameworks, instead of having manual scripts. Really interested in this one, especially now when Swift C++ interop is available. I would really like to help implement it.

@juraskrlec
Copy link

Is there any new info about this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself feature A feature request or implementation objective-c interop Feature: Interoperability with Objective-C PrintAsClang Area → compiler: The PrintAsClang library
Projects
None yet
Development

No branches or pull requests

7 participants