(I’m just starting off with rust, so please be patient)

Is there an idiomatic way of writing the following as a one-liner, somehow informing rustc that it should keep the PathBuf around?

// nevermind the fully-qualified names
// they are there to clarify the code
// (that's what I hope at least)

let dir: std::path::PathBuf = std::env::current_dir().unwrap();
let dir: &std::path::Path   = dir.as_path();

// this won't do:
// let dir = std::env::current_dir().unwrap().as_path();

I do understand why rust complains that “temporary value dropped while borrowed” (I mean, the message says it all), but, since I don’t really need the PathBuf for anything else, I was wondering if there’s an idiomatic to tell rust that it should extend its life until the end of the code block.

  • BB_C@programming.dev
    link
    fedilink
    arrow-up
    2
    arrow-down
    1
    ·
    edit-2
    3 months ago

    There is a general mechanism in Rust that allows language users to add their own sugar. It’s called macros 😉

    macro_rules! keep {
        (let $id:ident = $expr:expr => $($tt:tt)+) => {
            let $id = $expr;
            let $id = $id$($tt)+;
        }
    }
    
    fn main() {
        keep!{ let path = std::env::current_dir().unwrap() => .as_path() };
        println!("{path:?}");
    }
    

    You can remove let from the macro’s fragment specifier and invocation.

    • Ephera@lemmy.ml
      link
      fedilink
      arrow-up
      11
      ·
      3 months ago

      While macros are cool and it’s good to keep them as an option in the back of the mind, it should be clarified that you’re not supposed to immediately reach for macros for small things you don’t quite like about the language.

      Excessive macro use makes it impossible for others (including your future self) to read your code and there’s often good reasons why it’s designed like it is.

      • BB_C@programming.dev
        link
        fedilink
        arrow-up
        1
        arrow-down
        9
        ·
        3 months ago

        you’re not supposed to immediately reach for macros

        correct

        for small things you don’t quite like about the language.

        incorrect

        Excessive macro use makes it impossible for others (including your future self) to read your code

        N/A. the macro above is trivial.

        impossible for others to read your code and there’s often good reasons why it’s designed like it is.

        fiction

        • kelvie@lemmy.ca
          link
          fedilink
          arrow-up
          6
          ·
          3 months ago

          Oof, this brings back PTSD for a lot of us that have worked with developers like this ☝️

          • slowcakes@programming.dev
            link
            fedilink
            arrow-up
            1
            arrow-down
            1
            ·
            2 months ago

            Well, all developers give each other ptsd, never seen a clean code base in my career. They all turn to shit, because 90% developers don’t care, because it will be someone else’s problem later.

            That said, yeah don’t do weird custom code, where you have to keep context in your head to understand the code.