OCaml has had labeled arguments for decades, so I assumed other languages would have added something similar by now. In C-style, it would be like:

  createUser(user, ~isAdmin:true, ~sendWelcomeEmail:false)

  createUser user ~isAdmin:true ~sendWelcomeEmail:false

  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)

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

  pad_end("123", to: 5, with: ".")

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:

toggleMenu(true);

That’s clear enough. This tends to work when:

- the meaning is obvious

- the function is small and local

- there’s only one flag "

You can do this as a convention in javascript since 2015, but I haven't seen a library that does it:

    > function foo({a, b, c}) {
    ... return {x: a, y: b, z: c};
    ... }
    undefined
    > foo({a: 1, b: 2, c: 3})
    { x: 1, y: 2, z: 3 }
    > const a = 'A', b = 'B', c = 'C';
    undefined
    > foo({a, b, c})
    { x: 'A', y: 'B', z: 'C' }
    >

C# has that