We Have Named Arguments at Home | corrode Rust Consulting
corrode.dev
Steve Klabnik recently wrote about named arguments, optional arguments, default arguments, function overloading, and why most of that design space has historically made him nervous in Rust. I agree with Steve. In fact, I think I agree slightly more s…
  • FizzyOrange@programming.dev
    101·
    2 days ago

    I agree - Structs are kind of a nicer solution here. Especially because it’s pretty common to pass a whole set of options through the call stack.

    In Python land you end up with functions with 30 arguments and when they want to pass them anywhere they give up and use kwargs which are completely awful and should almost never be used.

    • TehPers@beehaw.orgEnglish
      4·
      2 days ago

      In Python land you end up with functions with 30 arguments and when they want to pass them anywhere they give up and use kwargs which are completely awful and should almost never be used.

      Unpack[T] exists, but nobody uses it sadly. Also, it’s probably better to just use a dataclass or something instead anyway, but nobody does.

        • TehPers@beehaw.orgEnglish
          1·
          1 day ago

          Their docs page just flat out doesn’t work on mobile, but based on the high level descriptions of the packages, these look like something I’d install on a project without asking and write in the AGENTS.md that it’s forbidden from using the more popular libraries in favor of those. (Our DS people, in general, can’t and won’t write code for shit, so it’s the only way to get them to use a new library.)

          • flying_sheep@lemmy.ml
            1·
            1 day ago

            I think we helped improve that in our field since as I said, I’ve been making pleasant APIs for like 8 years there. But I know the struggle.

  • BB_C@programming.dev
    3·
    2 days ago

    Remember that this has no runtime cost and is fully type-safe.

    For the sake of maximal accuracy, enum size overhead can become relevant sometimes. But a work-around exists (boxing the huge variant), and with or without boxing, the performance would still beat whatever other languages have to offer.

    Otherwise, good post (I would have to say that since it mostly rehashes points I made in previous comments 😉).

  • lad@programming.devEnglish
    2·
    2 days ago

    This one:

    fn resize(width: u32, height: u32) {}
fn offset(dx: u32, dy: u32) {}

let f: fn(u32, u32) = if resizing { resize } else { offset };

    gets rewritten to something non-equivalent:

    struct Size {
    width: u32,
    height: u32,
}

fn resize(size: Size) {}

// No more arguing about arguments
let f: fn(Size) = resize;

    But I would say that the original idea of applying wildly different functions depending on a flag shouldn’t be easily achievable, because it’s a bad idea a lot of times.