---

name: rust-port description: >- Port code from C, C++, Python, Go, JavaScript, or TypeScript into idiomatic Rust that keeps the original behavior: ownership instead of manual memory, Result instead of error codes and exceptions, enums instead of flag ints and magic strings, and tests that prove the port matches. Use this whenever the user asks to port, translate, convert, migrate, or rewrite code in Rust ("rewrite this in Rust", "what would this look like in Rust", "move this module to Rust"), even if they don't say "port". Pairs with the rust-best-practices skill, which covers the target code's style.

Rust port

The goal is the Rust a Rust developer would have written to solve the same problem, with the same observable behavior. A line-by-line transliteration (C written in Rust syntax, or Python with Box<dyn Any>) compiles but keeps every problem the original had and adds the borrow checker on top. Port the behavior, not the structure.

1. Understand the original before writing anything

1. Read the code and its tests, and anything that calls it, if you have it.
2. List the observable behavior: every public function, its inputs, its outputs, and every way it can fail. Include the quiet parts, which are where ports go wrong: ordering of results, how ties break, what happens on empty input, whitespace and case handling, integer limits, and what counts as an error versus a valid edge case.
3. Note what is incidental, meaning things the original only does because of its language: manual memory management, out-parameters, NULL returns, global state, fixed-size buffers, a class that exists only to group functions, or isinstance checks. These don't carry over.
4. If the original has a bug or an ambiguity, keep its behavior, flag it in the porting notes, and let the user decide. A port is not the place to silently fix things.

2. Port the tests first

Translate the original tests into Rust tests before porting the implementation. Keep one Rust test per original test, with a name that maps back to it, so a reader can check coverage. The tests are the definition of "same behavior". If the original has no tests, write characterization tests from the behavior list in step 1.

3. Design the Rust API, then implement it

Decide the public types and signatures from the behavior list, not from the original's shape. Then implement against the ported tests.

From C and C++

| In the original | In Rust | |---|---| | malloc/free, new/delete, create/destroy pairs | Owned types (String, Vec, Box) dropped automatically; Drop for anything else | | NULL meaning "absent" | Option<T> | | Error codes (-1, ERR_* defines), errno | Result<T, E> with an error enum, one variant per code, implementing Display and std::error::Error | | Out-parameters (int *err_line, long *out) | Return values: put the data in the Ok value or the error variant | | Flag bitmasks (FLAG_A \| FLAG_B) | An options struct with named fields and Default, or the bitflags crate; never a raw u32 | | char * plus length, strcmp, strcasecmp | &str/String, ==, eq_ignore_ascii_case | | Pointer plus count, iterator by index | Slices, iterators | | Fixed-size buffers and their truncation | Growable types; drop the limit unless the limit is behavior | | #define constants and macros | const, enums, and functions | | Global or static mutable state | A struct the caller owns | | strtol and friends | str::parse with the matching integer type; map parse failures to your error enum |

Don't write unsafe or use raw pointers unless the port must talk to C through FFI, and then confine it as the rust-best-practices skill describes.

From Python

| In the original | In Rust | |---|---| | An exception hierarchy | One error enum (or one per area) with a variant per exception class; data attributes become variant fields | | None as a value | Option<T> | | Strings used as a closed set (kind in ("build", "test")) | An enum, with FromStr and Display for the text form | | Dicts or classes used as records | Structs with named fields | | dict iteration order (insertion order is guaranteed) | Vec or an ordered map when order is observable; a plain HashMap silently changes output order | | Duck typing, isinstance | Traits or enums | | Unbounded int | A sized integer chosen on purpose, with overflow handled (checked_*) where input can be large | | sorted(..., key=...) | sort_by_key or sort_by; both are stable, like Python's | | str.splitlines(), strip(), isalnum() | lines(), trim(), char::is_alphanumeric; check edge cases such as \r\n, Unicode, and empty strings against the original | | try/except around a parse | ? with a mapped error, or match on the Result |

From Go, JavaScript, and TypeScript

• Go (value, error) returns become Result; nil becomes Option; interfaces become traits; goroutines and channels become threads with std::sync::mpsc or async tasks, depending on what the original needs.
• JavaScript null and undefined become Option; thrown errors become Result; plain objects become structs; numbers become a sized integer or f64, chosen on purpose.

4. Keep the port proportionate

A port that matches the original on every possible input is usually the wrong goal. Match it on the inputs it actually receives, and use Rust's standard library for the rest.

• Don't reimplement the source language's runtime. Use str::lines, str::trim, str::parse, and char methods, not hand-written copies of Python's splitlines, strip, int(), or repr(), or of C's locale-dependent isspace and strtol. Where Rust's behavior differs only on exotic input, such as Unicode digits, non-ASCII whitespace, or unbounded integers, list the difference in the porting notes instead of coding around it. Write a compatibility shim only when the user says those inputs occur.
• Don't grow the API. Port the public surface the original has, plus the standard trait impls Rust callers expect (Debug, Clone, Display, Error, FromStr, Default, and IntoIterator for collections). Skip builders, Index impls, FromIterator, Extend, and custom iterator types unless the original's callers need them.
• Keep the algorithm unless it's wrong. Swap in a different algorithm only to fix a real problem, such as quadratic behavior on realistic input, and say so in the notes.
• Check the size. Count code lines, excluding tests, comments, and doc comments. A port from C or C++ usually lands near the original's size. A port from Python or JavaScript usually lands at two to three times the original, because types, error enums, and their trait impls are explicit in Rust. Much more than that usually means one of the three habits above.

Differential testing against the original is worth doing, but a few dozen realistic and edge-case inputs answer the question. A fuzzing harness over millions of inputs usually just finds exotic divergences that belong in the notes.

5. Verify

Run these if a Rust toolchain is available, and fix everything before reporting:

cargo build
cargo test
cargo clippy --all-targets -- -D warnings

Every ported test must pass. If the original's tests can be run too, run them and compare results on the same inputs.

6. Write the porting notes

Alongside the code, write a short PORTING.md that a reviewer can check in a few minutes:

• API mapping: a table from each original function or type to its Rust equivalent.
• Test mapping: each original test and the Rust test that covers it.
• Deliberate differences: anything that now behaves differently and why, such as an out-of-memory error that no longer exists, a fixed buffer limit that's gone, or exotic input where Rust's standard library behaves differently from the original's.
• Preserved quirks: odd behavior kept on purpose, so nobody "fixes" it by accident.
• Verification: which commands you ran and their result, or a plain statement that you couldn't run them.

For the style of the Rust itself, follow the rust-best-practices skill if it is installed.