A more sensible error message for assertions on arrow functions

[sezanzeb]

Suggestion

🔍 Search Terms

List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.

• 2775
• arrow

✅ 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

const expectFoo = (bar: unknown): asserts bar is Foo => { ... };

This line should show a useful error message, like TSxxxx: Assertions cannot be used on a arrow-functions

📃 Motivating Example

💻 Use Cases

Instead it shows TS2775: Assertions require every name in the call target to be declared with an explicit type annotation. as error. And not where the assert is, but instead where the function is called.

#34523 (comment)

A better error message on this design limitation would have been nice instead of the confusing TS 2775

I also think this is extremely confusing. I just had to look that error up for the third time now, visiting the same StackOverflow post for the third time, and realizing that I had assertions on an arrow function again for the third time.

An error like TSxxxx: Assertions cannot be used on an arrow-function would be much better.

[MartinJohns]

But arrow-functions can be assertions. They just need an explicit type annotation, as mentioned in TS2775.

[sezanzeb]

Ah, this is what I get for only reading the title and then just scrolling all the way down

[sezanzeb]

That error pops up where I call that arrow function though, not where I declare it. Making me think I need to change something about the way I call it, or that the parameter I'm inserting is somehow wrong. I think this is part of the confusion.

[RyanCavanaugh]

The error message you're getting is telling you what's wrong

Assertions require every name in the call target to be declared with an explicit type annotation.

expectFoo (the call target) does not have an explicit type annotation. You can tell because there's no : after its name:

// Not annotated
const expectFoo = ...
// Annotated
const expectFoo: SomeType = ...

I'm open to a correct rewording of this error message if anyone has one.

[fatcerberus]

How come there’s not an equivalent error for never-returning functions? Instead they just don’t affect control flow at all and people report that as a bug :)

[sezanzeb]

every name in the call target

I also don't know what this is. Is the call target the function that is called? Why are there multiple "names" in the function?

My 3.5 years of javascript and half a year of typescript experience are not enough to understand this error. Idk. Am I not good enough? Or is this error message a bit too funky

[fatcerberus]

call target = the expression being called. So if you write a.b.c(d) then the call target is a.b.c and the names in it are a, b, and c—and every single one of those must have an explicit type annotation, if c is an assertion function.

Given that these are the rules, I’m not sure how to make the error any clearer myself. It has to do with the structure of the call site so is kind of technical in nature.

[typescript-bot]

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow or the TypeScript Discord community.

[erfanium]

Lost one hour of my life because of this confusing error. please re-open the issue

[a-non-a-mouse]

+1 to re-opening this. Needing to explicitly annotate the actual variable apart from its value is something that, AFAIK, doesn't exist anywhere else in TS. When I read the error, I read it as "arguments need to be annotated", and my internal response is "Well, they are...": (x: string)

Then I had to find #34523 to figure out exactly what the issue actually was.

const foo = (x: string): asserts whatever => { ... }

contains exactly the same info as

const foo: (x: string) => asserts whatever = (x) => {}

(and if you inspect them TS returns the same types) So if the issue is with internal complexity, cool, but the error should actually clarify what the issue is and how to fix it.