After looking over swift-bindgen's code, it seems that it's possible to manually alter ARC counts for arbitrary pointers, meaning that it should be possible to let the swift runtime know when rust is done with an SRObject by decrementing the corresponding ARC. This should avoid memory leaks that I believe exist at the moment, since I don't thing swift knows when rust is finished with a value.

How do I handle nil returned from a swift function? The *const pointer in SRObject is private, so I can't check result.0.is_null(). Any other option?

EDIT: Opened a PR: #5

The rest of the ecosystem mostly uses dual licensing under MIT + Apache, and so does the Rust project. See this issue as an example, and for steps on how to do it.

Should you choose to do it, you have the permission from me: I license past and future contributions to this project under the dual MIT/Apache-2.0 license, allowing licensees to chose either at their option.

Hey, just been wandering here and there when i landed on this project. This questions is out of pure curiosity as I am mostly a jr. programmer but rust<->swift interoperability looks like kind of exotic thing. I see that for both rust and swift its important to have access to the legacy of c world, but what are I some potential real world scenarios where swift-rust interop is a thing?

Just to make things clear - I am genuinely asking and appreciate the work done on this project!

Currently, string concatenation is used to determine the path to be output for cargo:rustc-link-search=native=, as seen here: https://github.com/Brendonovich/swift-rs/blob/1ca64300e3deedbd47d782d86770d5fc673ffaa4/src-rs/build.rs#L80

So if the package_root argument to link_swift_package does not end with a /, the build breaks, and it's not obvious to the user why that has happened.

This needs to be changed to use std::path's join mechanism instead of a simple string concatenation.

Currently, there's a build failure when link_swift_package() is called with package_root not ending in /. This happens because cargo:rustc-link-search is determined using string concatenation. This PR modifies it to use std::path join methods instead.

When trying to test this change, I realised that there were the following other miscellaneous issues, which I've fixed as well:

1. Removed Cargo.lock. This file is supposed to be committed to repo only by end binaries. Given that this crate is a library, it shouldn't be having this.
2. Add tests to the repo. Without this it would be difficult to continue to expand the work of this crate. cargo test now works.
3. Add Github Actions workflows to run cargo build and cargo test on every push to master branch, and for PRs.
4. Include crates.io, license and build status badges in README header. The build status would start working only after you've merged this PR.
5. Miscellaneous changes to code to satisfy rustfmt and clippy.

Thank you for this useful crate.

The version of Swift running on my M1 MacBook Pro does not output a runtime compatibility version string which causes the unwrap to fail in the build script. This small change should fix the issue but I am not sure how it will act on other systems so further testing is certainly required. Also removed native and static declarations as those also caused issues with my system.

Output of swift -version on my system swift-driver version: 1.26.9 Apple Swift version 5.5.1 (swiftlang-1300.0.31.4 clang-1300.0.29.6) Target: arm64-apple-macosx12.0

Hello. I'm making a Rust program that uses Swift libraries and developing it in a Linux environment (WSL2). Do you know if this binding library works in Linux environments, or not? Thank you in advance.

Changes:

• swift-rs now supports macOS 10.10 (OS X Yosemite) or higher
• build::link_swift takes an argument for the minimum macOS version. Eg. build::link_swift("10.10");
• Some docs

Closes #3

See downstream issue for more details: https://github.com/tauri-apps/tauri/issues/4314

In theory, I think the memory management mechanism being used on the Swift side is the issue.

https://github.com/Brendonovich/swift-rs/blob/1c309f652428ecc549fbe8eaccba4835a97d3aa8/src-swift/lib.swift#L66-L69

It seems like memory is being freed twice.