Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Narrowing the type of destructured object arguments #48220

Closed
5 tasks done
mindplay-dk opened this issue Mar 11, 2022 · 3 comments
Closed
5 tasks done

Narrowing the type of destructured object arguments #48220

mindplay-dk opened this issue Mar 11, 2022 · 3 comments
Labels
Duplicate An existing issue was already created

Comments

@mindplay-dk
Copy link

mindplay-dk commented Mar 11, 2022

Suggestion

πŸ” Search Terms

destructuring, narrowing, parameters, arguments

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

When a function only depends on a subset of the object properties of an argument, narrow the type.

πŸ“ƒ Motivating Example

interface X {
  a: number;
  b: number;
  c: number;
}

function f({ a }: X) {
  // ...
}

In this example, the function f does not depend on the entire X, but instead on a subset of that type, e.g. Pick<X, "a">.

While you could manually specify this type, there is no reason for any function to depend on properties that it can't even access in the first place - I would therefore suggest that the subset of that type be automatically determined and inferred, resulting in a function that doesn't demand values it can't actually either see or use.

πŸ’» Use Cases

In general, there is no point in passing arguments to functions that can't even see them - destructuring hides the original object, and the function only receives the individual properties; since it can't access the object itself, it ultimately doesn't matter what the type of that argument is.

If you had to, for example, mock the arguments to a function for testing, this makes that much easier to - in the example, you can simply call f({ a: 1 }) and that would be valid, without have to resort to as any, or explicitly type-hinting with Pick, neither of which make much sense.

⚠ Caveat

This being JavaScript, you can of course access the object using arguments[0] - so the type of this object could in fact matter.

However, the type of arguments[0] is always any, and so, in that case, there's no type safety either way; if the rest of the type is important, you probably aren't (and likely shouldn't be) destructuring the argument in the first place.

So this seems unlikely to affect anything other than things like currying and higher-order functions, where you wouldn't be destructing anyway - and so, it seems unlikely this will cause any adverse effects in practice.

What do you think?

@MartinJohns
Copy link
Contributor

MartinJohns commented Mar 11, 2022

Related comment: #42419 (comment)

Parameter destructuring is considered to be an implementation detail, not an externally-visible facet of the function signature, so we don't modify the callee's view of the call based on whether or not the function uses destructuring.

edit: Actually I'd say this is a duplicate of #42419.

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Mar 11, 2022
@RyanCavanaugh
Copy link
Member

I don't see how this would ship without looking like a bug.

function isEmptyArray({ length }: unknown[]) {
    return length === 0;
}
// No error???
isEmptyArray("hello world");

@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants