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-7494] Allow loading SPM frameworks at runtime and calling Swift functions on them #50037

Open
tkrajacic opened this issue Apr 22, 2018 · 0 comments

Comments

@tkrajacic
Copy link

tkrajacic commented Apr 22, 2018

Previous ID SR-7494
Radar None
Original Reporter @tkrajacic
Type New Feature
Additional Detail from JIRA
Votes 2
Component/s
Labels New Feature
Assignee None
Priority Medium

md5: d74ba92f6e0a0153771974e09e6705d7

Issue Description:

While it is possible to load Frameworks on macOS using `Bundle` it is still not possible to call functions that use Swift types (unless they are bridged to Obj-C).

On Linux this looks even more bleak. Bundle is mostly unimplemented and using `dlopen` only allows for calling C functions by casting them to the assumed signature.

So the first request would be (leaving out the macOS part for now) that it is possible to load an SPM generated dylib/framework on Linux and use the runtime to safely call methods on exposed classes. This should include all of Swift's types, not only C functions. This would allow for creating a useful "plugin" architecture using Swift (something that is sorely missing from the Swift story so far)

Later on this should be ported to macOS, so the Obj-C requirement goes away.

While ABI stability might be a concern here I think it is important to have this functionality even while the ABI is not stable. This would still be useful for cases where the "plugins" are compiled at the same time as the host application.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant