• 2 Posts
  • 30 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle




  • If all you do in the Err(e) => ... match arm is returning the error, then you absolutely should use the ? operator instead.

    If the match arm also converts the error type into another error type, implement the From trait for the conversion, then you can use ? as well.

    If you want to add more information to the error, you can use .map_err(...)?. Or, if you’re using the anyhow crate, .with_context(...)?.






  • Aloso@programming.devtoMemes@lemmy.mlNokia be like
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    My Fairphone is 4 years old, it has been dropped on the floor (even hard surfaces like rocks and asphalt) countless times. It still works and looks like new. It has a protective cover that covers the edges, but not the screen or the back. It still survived all these years without a scratch.










  • Discriminant is irrelevant and you’re not supposed to fuck with it

    It matters because the conversion between i32 and the Result is only “free” if they have the same layout (which they do not, because of the discriminant). So a more costly conversion method is required.

    And there is zero reason to use unsafe/transmute for this.

    You are right, because the compiler is able to optimize your code quite well. However, if that optimization were to break at some point (as there is no guarantee that an optimization will continue to work in the future), it would become less efficient.


  • Aloso@programming.devtoRust@programming.devCan I make Result<T, E> an integer?
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    1 year ago

    This is not possible, because Rust still stores a discriminant even when the enum values don’t overlap.

    As far as I can tell, the only situation where Rust doesn’t store a discriminant is when either the Ok or Err variant is zero-sized, and the other variant has a niche. So, Result&lt;(), ErrorEnum> can be represented as an integer, but Result can not.

    You can still use enums, and implement simple conversions like this:

    #[repr(i8)]
    pub enum Error {
        E1 = -1,
        E2 = -2,
        E3 = -3,
        E4 = -4,
    }
    
    #[repr(i8)]
    pub enum Success {
        S0 = 0,
        S1 = 1,
        S2 = 2,
        S3 = 3,
    }
    
    pub type LibResult = Result;
    
    pub fn number_to_result(value: i32) -> Option {
        match value {
            -4 ..= -1 => Some(Err(unsafe { std::mem::transmute(value as i8) })),
            0 ..= 3 => Some(Err(unsafe { std::mem::transmute(value as i8) })),
            _ => return None,
        }
    }
    
    pub fn result_to_number(res: LibResult) -> i32 {
        match res {
            Ok(value) => value as i32,
            Err(error) => error as i32,
        }
    }
    

    P.S. Sorry that the generics aren’t displayed due to Lemmy’s bad santiziation.


  • Iframes cannot access the main frame’s DOM if the iframe is from a different origin than the main frame, and they never share the same JavaScript execution context, so an iframe can’t access the main frame’s variables etc.

    It’s not required that iframes run in a different process, but I think they do at least in Chrome and Firefox if they’re from a different origin. Also, iframes with the sandbox attribute have a number of additional restrictions, which can be individually disabled when needed.