Design Doc

• As much as possible, the Rust API should match the C++ API. If there are any issues with wrapping a type or method, communicate this issue with the OIIO project team.
• Anything that can return an error must do through via a Result<T, E>. has_error, geterror, and other error related methods should be ignored and use the result instead.
• The Rust API should make use of traits in the Rust standard library where they make sense. For example, the Clone trait for copying ImageBufs and etc.
• Where ambiguous, use the Rust function/method name scheme (for example, new_* or from_* for constructors). See https://rust-lang.github.io/api-guidelines/naming.html
• OIIO's method naming contains both snake_case and camelCase names for functions/methods. Unless agreed by the OIIO project, use whichever format the function/method uses.
• Functions/methods should have tests for the API itself. If a result in the OIIO bindings do not match what the C++ API would do, then that's a bug.
• The public namespace in the Rust API should match the public namespace in the C++ API. For example, the ImageBuf namespace should be oiio::ImageBuf and not oiio::imagebuf::ImageBuf.
• The documentation for the types, modules, and methods should at least contain the documentation for the corresponding parts. See https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html for more information. Also,the documentation should contain the following:
  • Tests (these should pass)
  • Safety information (for unsafe functions and methods)
• We may make some rustc and clippy lints deny instead of warn. For example, public documentation, missing safety docs, etc.