Support failable initializers

[NiwakaDev]

Related to #235.

This PR supports failable initializers.

Something like:

// Rust side
#[swift_bridge::bridge]
mod ffi {
    extern "Rust" {
        #[swift_bridge(Equatable)]
        type FailableInitType;

        #[swift_bridge(init)]
        fn new() -> Option<FailableInitType>;
    }
}

// Swift side
let failableInitType = FailableInitType()
if failableInitType == nil {
    ~
} else {
   ~
}

See: Swift Documentation - Failable Initializers

[NiwakaDev]

Added #[allow(unused)] to fix the following warnings.

error: Argument "arg_typo" was not found in "fn some_function(..)"
 --> tests/ui/args-into-argument-not-found.rs:7:42
  |
7 |         #[swift_bridge(args_into = (arg, arg_typo))]
  |                                          ^^^^^^^^

error: Argument "bar" was not found in "fn some_method(..)"
  --> tests/ui/args-into-argument-not-found.rs:13:42
   |
13 |         #[swift_bridge(args_into = (foo, bar))]
   |                                          ^^^

warning: unused variable: `arg`
  --> tests/ui/args-into-argument-not-found.rs:19:18
   |
19 | fn some_function(arg: u8) {}
   |                  ^^^ help: if this is intentional, prefix it with an underscore: `_arg`
   |
   = note: `#[warn(unused_variables)]` on by default

warning: unused variable: `foo`
  --> tests/ui/args-into-argument-not-found.rs:25:27
   |
25 |     fn some_method(&self, foo: u8) {}
   |                           ^^^ help: if this is intentional, prefix it with an underscore: `_foo`

[chinedufn]

Instead of #[allow(unused)] let's do _arg and _foo. Less noisy.

[chinedufn]

Great work. Left some minor feedback. Thanks for implementing this. Great to see you back.

[chinedufn]

Let's make sure that we can use the type. This gives us more confidence that we didn't, say, bridge Some(bool) instead of Some(FailableInitType).

Maybe

let some = FailableInitType(true)
XCTAssertEqual(some!.count(), 123);

[chinedufn]

From now on all tests should say what we're verifying.

/// Verify that ...

This helps:

• new maintainers since it's easier to read English than code.
• forces the author to be clear about what behavior they're trying to test. Needing to explain ourselves makes us think critically about what we are doing and if we're covering enough cases.
• the reviewer noticing missing tests. For example, if the reviewer sees that what the test says that it is testing doesn't seem to match the code inside, they can comment on that. This tends to increase the quality of a test suite.

For simple stuff like this a sentence is fine.

[chinedufn]

It's test this in the codegen_tests module instead of here.

I think we should put all new codegen tests there going forward. This way there is a single place to find all codegen tests.

• more discoverable
• less confusion around where to put a test. there's always one place to put a codegen test instead of not knowing if it should go in generate_swift.rs or mod codegen_tests::*

[chinedufn]

nice

[chinedufn]

My feedback was minor, so feel free to Squash and merge after you address it.

When you Squash and merge remember to paste in your PR body as the commit message.

---

Alternatively you can rebase into a single commit, force push that, and then merge that. But Squash and merge essentially does the same thing.

[chinedufn]

Hello, hello. Still planning to land this?

[NiwakaDev]

Sorry. I'll address your review this weekend if possible.

[NiwakaDev]

@chinedufn
I guess it's suitable to add the test here.

Related: #276 (comment)

[chinedufn]

Looks good

[chinedufn]

Looks good just one small request then you can merge this.

Please remember to squash and merge and use your PR title for the commit title and PR body for the commit body.

[chinedufn]

Do we need these two DEVELOPMENT_TEAM lines? If not lets revert them.