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

[Swift] Would it be possible to use checked exceptions? #2179

Closed
LBeernaertProton opened this issue Jul 5, 2024 · 6 comments
Closed

[Swift] Would it be possible to use checked exceptions? #2179

LBeernaertProton opened this issue Jul 5, 2024 · 6 comments

Comments

@LBeernaertProton
Copy link

LBeernaertProton commented Jul 5, 2024

Is there any blocker currently that prevents uniffi from using checked exception in the generated binding code for swift?

@linabutler
Copy link
Contributor

Hi @LBeernaertProton!

Could you please say a bit more about what you mean by “using checked exceptions”? 😊 UniFFI does generate throwing Swift functions for methods and functions that are annotated with [Throws] in the UDL, and you can use [Error] interfaces to define the different error variants that you expect.

You can see an example of this in arithmetic. Here is its UDL, and here is how it’s called from Swift.

Maybe I’m misunderstanding what you’re asking, though?

Please let us know!

@LBeernaertProton
Copy link
Author

Hey @linabutler , what I meant is the the swift bindings that throw errors are not using checked exception notations which are supported by the language.

E.g.: This rust function

#[uniffi::export]
fn foo_bar() -> Result<(), MyError>

Is translated into:

func fooBar() throws;

What I would like to see:

func fooBar() throws (MyError);

I was wondering if there is currently anything preventing anyone from adding this to the generated bindings?

@linabutler
Copy link
Contributor

linabutler commented Jul 8, 2024

Ahh, I'm so sorry, I didn't realize you were talking about typed throws!

I was wondering if there is currently anything preventing anyone from adding this to the generated bindings?

I did some digging, and it looks like typed throws aren't actually shipping in any Swift release just yet! The documentation page you linked to is a little ahead of the game 😅

The latest release of Swift is 5.10.1, but SE-0413 is only available in the Swift 6 development snapshots. throws(Type) is a syntax error in Swift 5:

$ swift repl
Welcome to Apple Swift version 5.9.2 (swiftlang-5.9.2.2.56 clang-1500.1.0.2.5).
Type :help for assistance.
  1> struct MyError: Error {}
  2> func fooBar() throws (MyError) {}
error: error while processing module import: error: repl.swift:3:21: error: consecutive statements on a line must be separated by ';'
func fooBar() throws (MyError) {}
                    ^
                    ;

Digging a bit more, swiftlang/swift#74449 says:

The implementation of this experimental feature is not complete and it's not ready to be enabled in production. This experimental feature only gates the source-breaking parts of SE-0413: Typed throws, which will not be enabled by default in the Swift 6 language mode.

...So they might not be ready for the Swift 6 release, and it'll be a while before we can adopt them in the UniFFI bindings.

@LBeernaertProton
Copy link
Author

Oh, sorry about that, I did not realize that this was not properly supported in the current version of swift.

Thanks for you time.

@Sajjon
Copy link
Contributor

Sajjon commented Jul 24, 2024

@linabutler Hey! I might do a UniFFI PR later this fall when Xcode 16 GM is released - and with it Swift 6 - in which we can add a new config to uniffi.toml for Swift bindings. Perhaps experimental_typed_throws, like experimental_sendable_value_types I added in #2045, what do you think? In the generated Swift bindings we can use:

We can simply use

#if swift(>=6.0)
    func frobnicate throws (MyError) { ... }
#else
    func frobnicate throws { ... }
#endif

To support UniFFI consumers pre and post Swift 6.0.

I think that should work. What do you think?

(where experimental_typed_throws has no effect pre Swift 6.0 ofc...)

@linabutler
Copy link
Contributor

Sounds great to me, @Sajjon—thank you! 🏆

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants