Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Lossy argument names when spreading across parameter types

See original GitHub issue

Bug Report

🔎 Search Terms

argument names spread, parameter names spread

🕗 Version & Regression Information

  • This is the behavior in every version I tried

⏯ Playground Link

Playground link with relevant code

💻 Code

type Equality = (a: number, b: number) => boolean;

type GOOD = (...args: [...Parameters<Equality>]) => void;

type BAD = (...args: [...Parameters<Equality>, string]) => void;

🙁 Actual behavior

As shown here, the argument names are lost in if the argument list expression involves any arguments without names:


🙂 Expected behavior

It should infer the type of BAD as (a: number, b: number, args_2: string) => void.

🤔 Workaround

Declaring an extra function type with the additional arguments seems to work:

type Equality = (a: number, b: number) => boolean;

type Additional = (lol: string) => void; // 👈

type GOOD = (...args: [...Parameters<Equality>]) => void;

type BAD = (...args: [...Parameters<Equality>, ...Parameters<Additional>]) => void;

Inlining a function type seems to work too:

type Equality = (a: number, b: number) => boolean;

type GOOD = (...args: [...Parameters<Equality>]) => void;

type BAD = (...args: [...Parameters<Equality>, ...Parameters<(lol: string) => void>]) => void;

So there are known workarounds, although I would say these are non-obvious - it took me a long time to figure this out, and it’s just surprising how the second part of the parameter type expression seems to determine the outcome of the first part.

Issue Analytics

  • State:open
  • Created 2 years ago
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

RyanCavanaughcommented, Feb 28, 2022

The short answer is that the parameter -> tuple name feature is “best effort” (since nothing in the type system works/doesn’t work depending on these names), and the effort to handle this particular case simply hasn’t been done yet

jcalzcommented, Feb 28, 2022

I had no idea you could name tuple members! (is that a documented feature? I’ve never seen this before.)

Read more comments on GitHub >

github_iconTop Results From Across the Web

How does `Parameters<F>` keep arguments' names?
When the tuple is spread back to a function the original name is used. This association is not something directly visible from the...
Read more >
C++ Core Guidelines - GitHub Pages
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++.
Read more >
Passing Arguments by Position and by Name - Visual Basic
When you pass an argument by name, you specify the argument's declared name followed by a colon and an equal sign ( :=...
Read more >
Java Interoperability - GraalVM
intArg(1.1); //lossy conversion, TypeError! Note how the argument values have to fit into the parameter types. You can override this behavior using custom ......
Read more >
Changelog • tibble
List classes are no longer automatically treated as vectors. Symptoms: ... tibble() ignores NULL arguments, named or unnamed (#580).
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found