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

Expressing Rust Move-Only Types in Swift #4

Open
nvzqz opened this issue Nov 3, 2019 · 0 comments
Open

Expressing Rust Move-Only Types in Swift #4

nvzqz opened this issue Nov 3, 2019 · 0 comments

Comments

@nvzqz
Copy link
Owner

nvzqz commented Nov 3, 2019

In Rust, types that don't implement Copy are considered to be move-only and can only be copied via Clone or other means.

In Swift, there's currently no notion of moving a value. Reassignments of a value result in an implicit copy. For class types or anything that contains a class member, this will increment the strong reference count.

There seems to be three approaches to this:

  1. Retrofit a Move protocol that gives automagical move semantics.

    Pros:

    • Doesn't require Swift users to rewrite any existing code.

    • Allows for deinit on non-class types.

    Cons:

    • Wouldn't work in the context of generics. Implicit copying would still be the default there unless a generic type is specified as Move. Rust's move-only types work in generics because all types are assumed to be move-only unless a generic type is specified as Copy.
  2. Introduce a Copy protocol and assume move-only otherwise. Essentially, just copy Rust.

    Pros:

    • Allows for easier FFI when Swift types cross over into Rust-land.

    • Fine-grained control over move semantics types.

    • Works in the context of generics out-of-the-box.

    Cons:

    • Results in significant added complexity, increasing the learning curve. Implicit copying helps keep Swift succinct and expressive.

    • Massive source compatibility break. Requires stdlib and Swift users to rewrite all implicit copies and opt into Copy where appropriate.

  3. Introduce a special Move<T> wrapper type that gives a type move semantics.

    Pros:

    • Allows for basic move-only types.

    Cons:

    • Doesn't gain much. Really only makes existing code more verbose.
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

1 participant