Conciliating Rust results with a C-idiomatic Out<Error> parameter

[danielhenrymantilla]

This is basically an interesting discussion that stemmed from questions asked by @fjarri over #95.

Some context

The gist of it is that, given

fn returns_option() -> Option<…>;
fn returns_result() -> Result<…, …>;

and some Rust code calling into these sequentially, e.g.,

fn api_func (error: Option<Out<'_, Error>>)
  -> Option<usize>
{
    let x = returns_option()…?;
    let y = returns_result()…?;
    Some(x + y)
}

they had defined the following helpers:

fn write_error (_msg: &'_ str, _error: Option<Out<'_, Error>>) { … }

pub
trait Reportable<T> {
    fn report_error (self, msg: &'_ str, error: Option<Out<'_, Error>>)
      -> Option<T>
    ;
}
    
impl<T, E : Display> Reportable<T> for Result<T, E> { … }
    
impl<T> Reportable<T> for Option<T> { … }

thanks to which they ended up with:

Stage 0 / initial state

fn api_func (error: Option<Out<'_, Error>>)
  -> Option<usize>
{
    let x = returns_option().report_error("returns_option()", error)?;
    let y = returns_result().report_error("returns_result()", error)?;
    Some(x + y)
}

But this yields ownership-sematic-related errors about "use of moved value, error".

• Playground

[danielhenrymantilla]

Stage 1

The most direct way to tackle the problem is then to use &mut (re)borrows of the error, rather than consuming ownership of it at the first fallible operation:

pub
fn api_func (error: Option<Out<'_, Error>>)
  -> Option<usize>
{
+   let error = &mut { error };
    let x = returns_option().report_error("returns_option()", error)?;
    let y = returns_result().report_error("returns_result()", error)?;
    Some(x + y)
}

and then tweak the helpers accordingly.

• Playground

---

This does work, but @fjarri pointed out that borrowing the error allowed for either error messages to be leaked, or for error messages to be discarded, in case of a coding error, such as forgetting a ? on a fallible operation whose return value is ignored:

pub
fn api_func (error: Option<Out<'_, Error>>)
  -> Option<usize>
{
    let error = &mut { error };
    let _ = returns_option().report_error("returns_option()", error) ;
+                                                                   ^

    let y = returns_result().report_error("returns_result()", error)?;
    Some(y)
}

This, alas, compiles fine.

[danielhenrymantilla]

Stage 2 (nightly)

The issue before stemmed from trying to mix non-Rust-idiomatic patterns, such as out-parameters, completely in the middle of Rusty code (? operations).

In general, precisely because such translation is not a 100%-smooth operation, the trick is to have an internal function or block where 100%-rusty code is written, and then funnel with through a C/FFI-idiomatic translation/wrapping layer.

Using the nightly try blocks, for instance, this gives:

pub
fn api_func (error: Option<Out<'_, Error>>)
  -> Option<usize>
{
    error.unpack_result(try {
        let x = returns_option().context("returns_option()")?;
        let y = returns_result().context("returns_result()")?;
        x + y
    })
}

Which is quite readable and intuitive as non-FFI Rust code 🙂

• Playground

[danielhenrymantilla]

Final stage

Now, from the previous stage, the idea is now to try and reach stable Rust. try { … } blocks, especially -> Result-yielding ones, can easily be emulated by a macro that hides an inner closure.

But, given that we're gonna be feeding all this to a error.…(…) API nonetheless, why not make such API directly take such a closure, and skip the macro noise / complexity layer directly?

This thus yields what I think is the final and cleanest solution:

pub
fn api_func (error: Option<Out<'_, Error>>)
  -> Option<usize>
{
    error.try_(|| {
        let x = returns_option().context("returns_option()")?;
        let y = returns_result().context("returns_result()")?;
        Ok(x + y)
    })
}

• Playground

• or error.catch(|| { … }) etc., whatever name suits you best.

• Obviously it would be possible to still define a try_!() macro so as to write: let x = try_!(returns_option()); to avoid the .context() repetition, but that then depends of the code style preferences of the programmer 🙂

[fjarri]

Wow, thanks a lot! I do appreciate you taking the time to write up a thorough explanation.

The only thing I'd like to add here is that I don't think this issue is limited to FFI. I can easily imagine this kind of pattern being useful in pure Rust code, without any relation to unsafe operations.