3 ms·

Since Rust and C can agree on ABI and memory layout issues, you can move the code over function-by-function if you were so inclined, right? Declare the structs

• comex 11y ago
  You can, but idiomatic Rust code looks pretty different from idiomatic C code - to give a concrete example, int get_a_string(char **out) // returns error code could be translated literally as fn get_a_string(out: *mut *mut c_char) -> c_int but much preferable would be fn get_a_string() -> Result<String, Errcode> [where Result and String are standard library types; Errcode would be a custom enum.] I suppose you could go from the first to the second incrementally, then refactor to the third. But I'm not sure it'd work well.
  • randommodnar 11y ago
    Is there a solution yet in Rust to this problem of, monadic-ish constructs like Result and Option, but no nice way to chain them together without hideous nesting, like Haskell's "do" or Scala's "for"?
    • steveklabnik 11y ago
      We don't have HKT and therefore we can't have real do notation. The mdo crate provides a duck-typed macro. .and_then calls themselves aren't too bad, with the right whitespace.
    • comex 11y ago
      In the special case of Result, the new ? operator is going to subsume try! and offer more flexibility: https://github.com/rust-lang/rfcs/pull/243 https://github.com/rust-lang/rfcs/pull/243 (note that what was actually accepted differs from the text of the RFC, you need to scroll to the bottom) As steveklabnik says, there's nothing resembling generalized monadic do notation for now.
• kibwen 11y ago
  This presumes that functions are well-defined boundaries in your C codebase, which may not be true if one is leaning heavily on global state.