Support satisfies operator on functions

[dummdidumm]

Suggestion

🔍 Search Terms

satisfies function

✅ Viability Checklist

• 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

Support the satisfies operator to appear after a function

function foo () { } satisfies Bar

This was requested/mentioned in #47920 several times but never followed up on

📃 Motivating Example

satisfies is super handy to use, and you can already use it for arrow functions. Not having support for it on functions feels unintuitive and forces a certain coding style where people have to use arrow functions when they rather want to use functions.

💻 Use Cases

Typing a function while preserving its return type.

[bradennapier]

It is not the prettiest way to define a function but it does the job and the result is awesome - retains the actual types and therefore infers the generic of SpotServicesController whereas if i just did const binance: SpotServicesController i would need to do const binance: SpotServicesController<BinanceTickerResult>

Not to mention the IDE tips become much less useless without jumping around to diff files to track down what the type is:

[gfx]

This feature is absolutely useful for everyone, but there's already a feature request with implements keyword for the same purpose in 2019:

• Describe function signature using an interface  #34319

[xamir82]

Weird that this didn't make it to 4.9 :/
@RyanCavanaugh Sorry to tag you but just wanted to ask whether there's any chance this will be implemented in the near future? The satisfies feature just feels incomplete without it.

[aradalvand]

This should've honestly been implemented already; such a bummer.

[PooSham]

@gfx the difference is that implements would require you to define the type of the parameters. But anyone goes, the current situation is quite annoying.

[ekaradon]

I was looking for this suggestion. Upvoted it immediately. The first time I had to write some pages with Next, I was just thinking that I would replace lambda by function (for all the benefits that function has over lambda) and thought that satisfies would just work better by not erasing the return type but keeping it type safe nonetheless. Really surprised that an exception for function has been made here.

It's such a recurring use case. It would be awesome to get it. Especially because it would be consistent with just all the others use cases where satisfies is valid. Please make it a reality! 😃

[aradalvand]

Functions are possibly the most common use case for satisfies and they're not supported.
Brilliant.

[hanneswidrig]

What can we do to give this more visibility, I see "awaiting more feedback" is one of the tags on this issue?

[maslennikov]

This is what I believe would be the most valuable use-case of satisfies for me

[maslennikov]

Hey @RyanCavanaugh could you provide any feedback on status of this topic? Maybe we could add any more feedback to raise its visibility in typescript's backlog?

[mon-jai]

Bump

[xamir82]

@RyanCavanaugh Could you look at this please.

[icholy]

Guys, I'm subscribed to this issue so that I can see updates on its progress. The maintainers are aware of this issue and spamming in here is annoying for everyone involved. Unless you have something meaningful to add the to the conversation, please use the emoji reactions to indicate your support/interest.

[lrowe]

This already seems to be supported so long as you add parentheses:

export default (function f(x: number) { return String(x); } satisfies (x: number) => string);

[francescosalvi]

This already seems to be supported so long as you add parentheses:

export default (function f(x: number) { return String(x); } satisfies (x: number) => string);

seems to works either way, but perhaps stylistically the closing parenthesis should go right before satisfies ?

[PooSham]

This already seems to be supported so long as you add parentheses:

export default (function f(x: number) { return String(x); } satisfies (x: number) => string);

Yeah but then you have to type the parameter types again, it would be preferable to use satisfies only for the return type

[alextbok]

This already seems to be supported so long as you add parentheses:

export default (function f(x: number) { return String(x); } satisfies (x: number) => string);

Yeah but then you have to type the parameter types again, it would be preferable to use satisfies only for the return type

At risk of stating the obvious, if the goal is strictly to declare the parameter type only once in this example (and in general) you can rely on inference from the satisfied type (similar to the return type):

export default (function f(x) { return String(x); } satisfies (x: number) => string);

[snarbies]

Even if there are some slightly awkward ways to manage this with function expressions and arrow functions, it would be nice if there was a solution for function declarations, which seems to be the original ask.

[wesbos]

all the solutions have downsides - added parenthesis, using a function expression / arrow function, having to double type the arguments, creating an anonymous function that isn't accessible in the same file (the above example).

We just want to be able to type a functions Params and return types in a single shot and have the values inferred. and satisfies would work?

type RouteHandler<T extends object> = (body: T) => Promise<Response>;

async function handleRoute({ name }) {
  return new Response.json({ message: `Hello ${name}` });
} satisfies RouteHandler<{ name?: string }>

[PooSham]

This already seems to be supported so long as you add parentheses:

export default (function f(x: number) { return String(x); } satisfies (x: number) => string);

Yeah but then you have to type the parameter types again, it would be preferable to use satisfies only for the return type

At risk of stating the obvious, if the goal is strictly to declare the parameter type only once in this example (and in general) you can rely on inference from the satisfied type (similar to the return type):

export default (function f(x) { return String(x); } satisfies (x: number) => string);

I wouldn't say that's stating the obvious :) I didn't realize that satisfies on the whole function would make typescript infer the parameter inside the function, but when you mention it it's obvious that typescript needs to do this to ensure type safety.

I would still prefer the syntax of putting the satisfies keyword for the return type after the parameters, but this is semantically what I'm after. Thank you!

[louwers]

If this is implemented, please don't forget about JSDoc.

Example

export type MyFunc<R extends "a" | "b" | "c" = "a" | "b" | "c"> = () => R;

This currently works

/** @satisfies {MyFunc} */
const testB = () => "test";
                 // ^ Type '"test"' is not assignable to type '"a" | "b" | "c"'.ts(2322)

This does not:

/** @satisfies {MyFunc} */
function testA() {
  return "test";
}

I think the title and description of this issue should be updated to say: allow satisfies on function declarations.

[NatoBoram]

Related:

• Rule Change: [func-style] Allow type-annotated variable declaration eslint/eslint#18842
• Base rule extension: [func-style] Allow type-annotated variable declaration typescript-eslint/typescript-eslint#8488