One nice unexpected side effect is that I end up with more consistency in variable naming when using a param object in order to benefit from object definition shortcuts.

ie I will usually write something like `const firstName = getFirstName(); doTheThing({ firstName });` rather than `const fName = getFirstName(); doTheThing({ firstName: fName });`

string combineName(string first, string last);

Okay, I assume the result is the full name, but I don't really know that like I would if the return had a name in the header. (The function can be getFullName, yes, but that's so simple it doesn't matter).

But in native languages like C/C++/etc, this pattern usually hurts performance. Separate arguments go into registers (faster but depends on number of arguments), while structs often involve indirection, and sometimes alignment/padding issues. Also, passing a const struct doesn’t guarantee the fields inside are truly const.

That said, it's context dependent. If you're passing stuff through multiple layers or want a more stable function signature, using a struct can be cleaner. Just not something I’d generalize to any language or any use case.

I don't think we are near said dream, yet.

1. Most of the time, arguments are not the same type, so if you're using TypeScript, you're already getting errors at this point. In your example, only first/last names might get mixed up. And if you still get those wrong while writing that code, you're just phoning it in atp and maybe should take a day off.

2. The same TypeScript that checks your types, also lets you see the signature when hovering over the function.

In real world coding, this isn't an issue, and you'll probably give up keeping this "rule" after a year or two. But good that you're at least thinking about these kinds of things.

https://testing.googleblog.com/2024/05/avoid-long-parameter-...