News for hackers. Stuff that matters.
Re:N-Params vs. Single Param by hyperhello on Thursday April 17, 2025 @03:24PM (#43721066)
What bothers me a lot is that return values can't have a name. Suppose I have a function

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

Re:N-Params vs. Single Param by geakstr on Thursday April 17, 2025 @03:36PM (#43721183)
Some languages allow to define type alias, name of this type can be self-explanatory:

  type FullName = string;
  function combineName(first: string, last: string): FullName;
Also documentation comment for function is what specifically solves this - describes what function does and returns.
Re:N-Params vs. Single Param by hyperhello on Thursday April 17, 2025 @03:41PM (#43721252)
Neither really addresses the issue. Making a type for a single kind of string seems like an abuse of types just to shoehorn the documentation in. Documentation can be used directly of course, but that moots all of this -- just document? Yeah, but naming the variable is super quick compared to either.
Re:N-Params vs. Single Param by oneoverten on Thursday April 17, 2025 @07:27PM (#43723334)
Variable names is just documentation. Having types that can assert some condition on the underlying value is not even comparable to "having a named return variable". (just document? just name variables?) You don't care about what the name of the returned value is, you care about what *it is*.
Re:N-Params vs. Single Param by avandekleut on Thursday April 17, 2025 @10:45PM (#43724464)
Typescript nukes primitive aliases like this sadly. Intellisense will just infer it as "string".
Re:N-Params vs. Single Param by disillusionist on Thursday April 17, 2025 @03:41PM (#43721246)
you can do this rather easily by returning an object rather than a primitive. if you're using a language like TypeScript, destructuring the resulting returned object is rather trivial and (in my opinion) delightful to read. eg

  function combineNames({ first, last }) {
    const fullName = `${first} ${last}`;
    return { fullName };
  }
  const { fullName } = combineNames({first: 'John', last: 'Doe' });
Re:N-Params vs. Single Param by vbezhenar on Friday April 18, 2025 @11:20AM (#43728892)
For some reason React prefers to return arrays. I never understood the reason.

  const [state, setState] = useState(initialState)
instead of

  const {state, setState} = useState(initialState)
Re:N-Params vs. Single Param by wvenable on Thursday April 17, 2025 @07:10PM (#43723203)
I fail to see the distinction, for documentation purposes, of this versus just giving it that `getFullName` function name.

A more complex example will probably return a more complex type that is more self-documenting. If the type is a single scalar value then I don't see the value of adding another name here.

Re:N-Params vs. Single Param by avandekleut on Thursday April 17, 2025 @07:57PM (#43723545)
Similarly to passing an object argument, you can return an object.

Then pair it with destructuring assignment!

`const { fullName } = getName({ firstName, lastName )}`

Re:N-Params vs. Single Param by mpweiher on Friday April 18, 2025 @02:50AM (#43725649)
Name the function/method as the thing it "returns".

In fact, just forget that it is a function that does something. Treat it as the thing it returns.

string fullName( string firstName, string lastName )