Even though in OCaml's functional style it is actually like this:
createUser user ~isAdmin:true ~sendWelcomeEmail:false
Using the fact that a variable named exactly like a labeled argument is automatically assigned to it, we can make the call more concise (especially if reusing existing variables):
let isAdmin = true in
let sendWelcomeEmail = false in
createUser user ~isAdmin ~sendWelcomeEmail
It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:
fn foo(namedParam internalName: bool) { // use internalName here }
fn foo(unnamedParam: bool)
Think the issue is not with named parameters per se, but with mixing domain logic = there are two different user creation flows, that should be doing two different things (or mostly different things), but are guarded with boolean flag.
As author points out: "So I’ll usually just make it explicit:
createAdminUser(user);
createRegularUser(user);
Now there’s not much left to interpret. To be fair, this isn’t always bad. Sometimes this is completely fine:
This is one of the things I've loved about Gleam, one local variable name and potentially an external label that callers can use to annotate themselves. For example, a function declaration may look like this:
pub fn pad_end(
string: String,
to desired_length: Int,
with pad_string: String,
) -> String
