6 ms·

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

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) 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

lostmsu 4mo ago
C# has that
MathMonkeyMan 4mo ago
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' } >
Dagonfly 4mo ago
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)
eithed 4mo ago
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 "
jdiff 4mo ago
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 And a call to this function may look like: pad_end("123", to: 5, with: ".")

lostmsu 4mo ago

C# has that

MathMonkeyMan 4mo ago

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' } >

Dagonfly 4mo ago

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)

eithed 4mo ago

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 "

jdiff 4mo ago

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 And a call to this function may look like: pad_end("123", to: 5, with: ".")