49

See also the discussion for Klabnik's Arguing about arguments

top 7 comments
sorted by: hot top new old
[-] FizzyOrange@programming.dev 11 points 3 weeks ago* (last edited 3 weeks 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.org 5 points 3 weeks 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.

[-] flying_sheep@lemmy.ml 3 points 3 weeks ago* (last edited 3 weeks ago)

We are migrating to this (https://scverse.org/)

But that's mostly because yours truly keeps pushing API design improvements

[-] TehPers@beehaw.org 1 points 3 weeks 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 points 3 weeks 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 4 points 3 weeks 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 ๐Ÿ˜‰).

[-] sukhmel@programming.dev 3 points 3 weeks 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.

this post was submitted on 24 Sep 2026
49 points (100.0% liked)

Rust

8328 readers
18 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 3 years ago
MODERATORS