Unnecessary `unsafe` block…

language design
21 
    // SAFETY: This is safe because we're going to uphold all the invariants.
    let foo = unsafe { // ← still doesn’t directly allow unsafe operations
        let x = safe_preparation_operation(MAGIC_SAFEWORD);
        x.prepare_even_more_safely();
        // SAFETY: This is safe because x has been prepared so safely.
        let result1 =  x.unsafe this_is_where_the_unsafe_magic_happens();
        //                 ↖ still required despite the outer `unsafe` block
        gimme_that_result(result1);

        // SAFETY: Our ffi is all good.
        let final_result = x.unsafe this_is_where_the_unsafe_ffi_happens();
        // (admitted, you only know that this is about FFI, when looking at the docs
        // of `this_is_where_the_unsafe_ffi_happens`, but at least it’s very
        // clear where exactly you have to look)

        final_result
    };

Shouldn't you split this into two unsafe blocks, since the FFI is all good and doesn't depend on the previous operations to be sound?

22

In my head, in the original example, even though it was a kind of “foobar” pseudo code without meaning, I did assume that the two unsafe operations might be somehow related, and I didn't question that assumption in my later answer you're quoting. I didn't express this explicitly (the original question was supposed to be fairly general, the example just an illustration). Of course if they aren't related, which is a legitimate interpretation of this foobar-code (and may or may not be what @toc had in mind while introducing the assumption that there might be some kind of “FFI”-related effect here), then two blocks make more sense.

23

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.