This! There’s also a longstanding open issue on rust to allow a similar way to pass keyword/named arguments. IMO every modern language should have something like this. Makes all the difference when reading code.
Inlay hints from your editor are a good help, but this should be built into the language.
I don’t care about the color of the train or the amount of wheels, I just want the default train with a few changed parameters.
If you do named parameters in rust, you would need to set every parameter. The only way to not set every parameter is to give a special meaning to the Default trait. But that is uncommon to happen in rust. And many structs that could easily derive Default don’t.
If you do named parameters in rust, you would need to set every parameter.
If that’s the condition, yeah, it’s bad. The good thing about how Python handles it is that they can still be mandatory or optional. And that makes it a more flexible option than the builder pattern because it applies to any function or method.
Right cause the boolean isn’t a named type. If you have two possible states that can be represented with a boolean, or an enum of the two possible states which embeds more info into the callsite
This! There’s also a longstanding open issue on rust to allow a similar way to pass keyword/named arguments. IMO every modern language should have something like this. Makes all the difference when reading code.
Inlay hints from your editor are a good help, but this should be built into the language.
Not saying that named parameters are bad, but the builder pattern serves the same purpose and imo it’s more ergonomic.
TrainBuilder::new() .with_electric_motor(true) .with_width(1.0) .build()I don’t care about the color of the train or the amount of wheels, I just want the default train with a few changed parameters.
If you do named parameters in rust, you would need to set every parameter. The only way to not set every parameter is to give a special meaning to the
Defaulttrait. But that is uncommon to happen in rust. And many structs that could easily deriveDefaultdon’t.If that’s the condition, yeah, it’s bad. The good thing about how Python handles it is that they can still be mandatory or optional. And that makes it a more flexible option than the builder pattern because it applies to any function or method.
Rust doesn’t need this as much because it has enums so you can just do
create_user(user, Role::Admin, Notify::None).you can have a better data structure in any language, but rarely someone will bother doing that for booleans
Yeah I do wonder if we need an easier way to declare these things because programmers are lazy and even in Rust I wouldn’t always bother.
You can kind of do it in Typescript with strings:
function create_user(role: "admin" | "normal")But of course the downside is they are strings at runtime. I’m sure it’s possible though.
Right cause the boolean isn’t a named type. If you have two possible states that can be represented with a boolean, or an enum of the two possible states which embeds more info into the callsite