0.1.25

• Add attribute for auto-implementing the Swift Identifiable protocol #21

This release introduces the #[swift_bridge(Identifiable)] attribute
which is used to generate an Identifiable protocol implementation
for a type.

For example:

// Rust

#[swift_bridge::bridge]
mod ffi {
    extern "Rust" {
        type SomeType;

        #[swift_bridge(Identifiable, swift_name = "someFunction")]
        fn some_function(&self) -> i16;
    }
}

// Generated Swift
// (rough example, the real generated code looks a little different)

class SomeType {
    // ...
}
extension SomeType: Identifiable {
    var id: UInt16 {
        return self.someFunction()
    }
}

---

• Fix RustStr bug due to incorrect buffer size

0.1.24

• Support Vec<OpaqueRustType> as a fn arg #20

For example, the following signature is now possible:

#[swift_bridge::bridge]
mod ffi {
    extern "Rust" {
        type ARustTypeInsideVecT;

        fn rust_reflect_vec_opaque_rust_type(
            arg: Vec<ARustTypeInsideVecT>,
        ) -> Vec<ARustTypeInsideVecT>;
    }
}

0.1.23

• Support Option<OpaqueRustType> in functions #19

For example, the following is possible as of this release.

#[swift_bridge::bridge]
mod ffi {
    extern "Rust" {
        type SomeType;
        type AnotherType;

        fn some_function (arg: Option<SomeType>) -> Option<AnotherType>;
    }
}

pub struct SomeType { /* */ }
pub struct AnotherType(/* ... */);
fn some_function(arg: Option<SomeType>) -> Option<AnotherType> { /* ... */  }

0.1.22

• Make generated Swift structs public #18

Allows you to (at this time manually) implement certain protocols, such as Identifiable, on generated structs in Swift.

Without this you get an error:

Property 'id' must be declared public because it matches a requirement in public protocol 'Identifiable'

---

In the future we might allow the user to control whether or not the generated struct is public (perhaps by declaring pub on the struct declaration in the bridge module..) but let's hold off on that until we are more familiar with Swift's Access Control.

0.1.21

• Fix span when reporting an incorrect argument type.

For example, given this bridge module...:

#[swift_bridge::bridge]
mod ffi {
    extern "Rust" {
        #[swift_bridge(rust_name = "some_function")]
        fn fn1(arg: &str);
    }
}

fn some_function(_arg: u16) {}

Before this release

┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0308]: mismatched types

 --> tests/ui/incorrect-argument-type.rs:1:1
  |
1 | #[swift_bridge::bridge]
  | ^^^^^^^^^^^^^^^^^^^^^^^ expected `u16`, found `&str`
  |
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈

As of this release

┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
error[E0308]: mismatched types
  --> tests/ui/incorrect-argument-type.rs:4:16
   |
 4 |         fn fn1(arg: &str);
   |                ^^^^^^^^^ expected `u16`, found `&str`
┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈

---

• Fix using the into_return_type attribute when returning shared structs.

A recent regression broke this behavior.
Added an integration test to prevent this from breaking again.

0.1.20

• It is now possible to use Option<T> in extern "Rust" function arguments. #15

For example, as of this release the following is now possible.

#[swift_bridge::bridge]
mod ffi {
    extern "Rust" {
        // You can now expose functions that have Option<T> arguments.
        fn some_function(count: Option<u32>, message: Option<String>);
    }
}

fn some_function(count: Option<u32>, message: Option<String>) {
    // ...
}

So far we support:

Option<Integer>s such as `u8` and `i64`
Option<f32>, Option<f64>
Option<bool>

Option<String>
Option<&str>

---

It is already possible for functions to return Option<T>.

In the future we will support Option<T> fields in shared structs.

0.1.19

• Fix parsing multiple function attributes b15b365

• Fix parsing opaque Rust doc comments f4d8b73

v0.1.18

• Add support for already declared structs so that you can use the same struct across multiple bridge modules #9