swift_bridge/std_bridge/
result.rs

1#[repr(C)]
2#[doc(hidden)]
3// Bridges `Result<T, E>` where `T` and `E` are both able to be encoded
4// as a pointer.
5//
6// For example, suppose we have the following bridge module:
7//
8// ```
9// #[swift_bridge::bridge]
10// mod ffi {
11//     extern "Rust" {
12//         type TypeA;
13//         type TypeB;
14//
15//         fn x() -> Result<TypeA, TypeB>;
16//     }
17//
18//     // ---------------------------------
19//
20//     enum TypeC {
21//         Variant1,
22//         Variant2
23//     }
24//     struct TypeD {
25//         field: u8
26//     }
27//
28//     extern "Rust" {
29//         fn y() -> Result<TypeC, TypeD>
30//     }
31// }
32// ```
33//
34// When can encode `Ok(TypeA)`, as `ResultPtrAndPtr { is_ok: true, ok_or_err: *mut TypeA as _ }`.
35// And we can encode `Err(TypeB)` as `ResultPtrAndPtr { is_ok: false, ok_or_err: *mut TypeB as _ }`.
36//
37// However, `Ok(TypeC)` and `Err(TypeD)` do not get encoded using `ResultPtrAndPtr` since we do not
38// pass transparent enums or transparent structs across the FFI boundary using pointers.
39//
40// Instead, we would an FFI representation for `Result<TypeC, TypeD>` at compile time.
41// See `crates/swift-bridge-ir/src/codegen/codegen_tests/result_codegen_tests.rs` for examples of
42// how we generate custom `Result` FFI representations at compile time.
43pub struct ResultPtrAndPtr {
44    pub is_ok: bool,
45    pub ok_or_err: *mut std::ffi::c_void,
46}
swift_bridge/std_bridge/result.rs

swift_bridge/std_bridge/
result.rs
