Support satisfies operator on functions

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.

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:

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

Ryan Cavanaugh (@RyanCavanaugh)

Weird that this didn't make it to 4.9 :/
Ryan Cavanaugh (@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.

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

FUJI Goro (@gfx)

FUJI Goro (@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.

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! 😃

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

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

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

Ryan Cavanaugh (@RyanCavanaugh)

Hey Ryan Cavanaugh (@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?

Bump

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) Could you look at this please.

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.

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

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 ?

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

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

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.

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 }>

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!

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.

e.g.

function foo satisfies Bar (param1: Baz) { /* ... */ }

Rebecca Stevens (@RebeccaStevens)

Rebecca Stevens (@RebeccaStevens) I think in that approach the readability would suffer if the type were anything non-trivial. e.g. imagine:

function foo satisfies NonNullable<SomeInterface>['someMemberName'] (param1: Baz) { /* ... */ }

IMO, it creates too much distance between the function name and the parameter list.

just noticed this isn't possible today - would be really helpful for an API I'm exposing to users if I could just export a function type they could use to both type check and type hint their own functions

Navigation Menu

Repository navigation

Support `satisfies` operator on functions #51556

Suggestion

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

📃 Motivating Example

💻 Use Cases

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support satisfies operator on functions #51556

Description

Suggestion

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

📃 Motivating Example

💻 Use Cases

Activity

bradennapier commented on Nov 17, 2022

gfx commented on Dec 5, 2022

xamir82 commented on Dec 11, 2022

aradalvand commented on Jan 4, 2023

PooSham commented on Feb 22, 2023

ekaradon commented on Mar 4, 2023

aradalvand commented on Mar 4, 2023

hanneswidrig commented on Apr 19, 2023

maslennikov commented on Jun 6, 2023

maslennikov commented on Jun 17, 2023

mon-jai commented on Jul 1, 2023

xamir82 commented on Jul 2, 2023

icholy commented on Jul 2, 2023

lrowe commented on Mar 1, 2024

francescosalvi commented on Mar 1, 2024

PooSham commented on Mar 1, 2024

alextbok commented on Mar 1, 2024

snarbies commented on Mar 1, 2024

wesbos commented on Mar 1, 2024

PooSham commented on Mar 13, 2024

louwers commented on Oct 6, 2024

NatoBoram commented on Oct 7, 2024

RebeccaStevens commented on Apr 24, 2025

mark-dr commented on Apr 24, 2025

marcospgp commented on Jun 27, 2025

rafa-br34 commented on Jan 22, 2026

louwers commented on Jan 22, 2026

lolmaus commented on Jan 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Support `satisfies` operator on functions #51556