`default` keyword is offered in expression-bodied arrow function completions

[DhineshPonnarasan]

Bug Report

Search Terms

• arrow function completion
• default keyword completion
• expression-bodied arrow function
• keyword completions
• completionListAtEndOfWordInArrowFunction

Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about keyword completions in expression-bodied arrow function contexts.

Playground Link

Playground link with relevant code: https://www.typescriptlang.org/play?#code/PTAEFkE9QYwewCYFNQHM5IM6gBZIE5JA

Code

(d, defaultIsAnInvalidParameterName) => d

(d, defaultIsAnInvalidParameterName) => default

Actual behavior

At the expression-bodied arrow function completion position, default is offered as a keyword completion.

Expected behavior

default should not appear as a keyword completion in expression-bodied arrow function expression context.

Additional information about the issue

There are already nearby fourslash tests that appear to acknowledge this behavior as undesirable:

• tests/cases/fourslash/completionListAtEndOfWordInArrowFunction02.ts
• tests/cases/fourslash/completionListAtEndOfWordInArrowFunction03.ts

I also traced the completion path locally and confirmed the keyword currently comes from the generic FunctionLikeBodyKeywords filtering path.

[mkantor]

default isn't special in this regard. Tons of syntactically- and semantically-invalid completions appear in this position, including:

• JavaScript keywords like case, catch, const, do, else, export, etc
• TypeScript keywords like as, asserts, declare, infer, keyof, etc
• Built-in type names like any, bigint, boolean, etc

[DhineshPonnarasan]

@mkantor Thanks, that makes sense — I agree this is broader than just default.

I checked additional completions in the same expression-bodied arrow function context and saw other entries that also don’t appear valid as expression continuations, including statement-oriented JS keywords and some TS/type-space keywords.

So this is likely better framed as the completion set for this context being overly permissive in general, rather than a single-keyword issue.

I’ll do a bit more investigation to separate intentional behavior from accidental behavior before proposing any concrete change.

default isn't special in this regard. Tons of syntactically- and semantically-invalid completions appear in this position, including:

• JavaScript keywords like case, catch, const, do, else, export, etc
• TypeScript keywords like as, asserts, declare, infer, keyof, etc
• Built-in type names like any, bigint, boolean, etc

[danyalahmed1995]

I confirmed this reproduces locally with the existing fourslash coverage. completionListAtEndOfWordInArrowFunction02.ts and 03.ts both currently pass while expecting default to be present, and 02 already has a TODO noting that default should not be included at an expression location.

The completion appears to come from the generic FunctionLikeBodyKeywords path in src/services/completions.ts, so this does not look specific to default. The same path also admits other statement-oriented keywords that are not valid expression continuations in this arrow expression-body position.

Because of that, a default-only filter seems too narrow and would leave most of the underlying behavior unchanged. This probably needs a broader, carefully scoped expression-position keyword filter if maintainers think this category is worth addressing.

[DhineshPonnarasan]

I confirmed this reproduces locally with the existing fourslash coverage. completionListAtEndOfWordInArrowFunction02.ts and 03.ts both currently pass while expecting default to be present, and 02 already has a TODO noting that default should not be included at an expression location.

The completion appears to come from the generic FunctionLikeBodyKeywords path in src/services/completions.ts, so this does not look specific to default. The same path also admits other statement-oriented keywords that are not valid expression continuations in this arrow expression-body position.

Because of that, a default-only filter seems too narrow and would leave most of the underlying behavior unchanged. This probably needs a broader, carefully scoped expression-position keyword filter if maintainers think this category is worth addressing.

@danyalahmed1995, Thanks for the detailed analysis! That matches what I found tracing through the code.

You're right that a default-only fix would be too narrow. The real issue is in tryGetFunctionLikeBodyCompletionContainer — when an arrow function has an expression body (not a block body), the code still routes through the FunctionLikeBodyKeywords path, which was designed for block bodies. Expression bodies need a tighter keyword set since only expression-valid continuations should appear there.

A proper fix would likely need a new filter variant (e.g., ExpressionBodyKeywords) that excludes statement-oriented keywords like default, case, catch, do, else, export, declare, etc. that are not valid in expression positions.

[DhineshPonnarasan]

@mkantor , @danyalahmed1995 , Thanks for the context. Given that this affects many keywords beyond default, I'd like to attempt a broader fix scoped to arrow function expression bodies — filtering out keywords that cannot appear in expression position (like case, catch, do, else, export, declare, infer, etc.) while keeping block-body behavior unchanged.

Would maintainers be open to a PR with that scope? Happy to start with a failing test first if that helps.

[danyalahmed1995]

@DhineshPonnarasan That broader scope matches what I found as well. I intentionally avoided opening a code PR immediately because this is not really a default-only issue. The problem seems to be that arrow expression bodies still flow through the broader function-like body keyword path, so fixing only one keyword would leave the underlying behavior mostly unchanged.

I also wanted to be careful because this touches completion filtering behavior that could affect a wider set of keywords and baselines. Given the repo’s current maintenance expectations, I figured it was better to first confirm whether maintainers want this category addressed before spending reviewer time on a broader implementation.

If maintainers are open to it, I think the clean path would be:

1. add failing tests for arrow expression bodies showing the invalid statement-position keywords,
2. introduce a narrower expression-position keyword filter,
3. keep block-body completions unchanged.

Happy to collaborate with you or compare findings if maintainers approve of it.

[DhineshPonnarasan]

@DhineshPonnarasan That broader scope matches what I found as well. I intentionally avoided opening a code PR immediately because this is not really a default-only issue. The problem seems to be that arrow expression bodies still flow through the broader function-like body keyword path, so fixing only one keyword would leave the underlying behavior mostly unchanged.

I also wanted to be careful because this touches completion filtering behavior that could affect a wider set of keywords and baselines. Given the repo’s current maintenance expectations, I figured it was better to first confirm whether maintainers want this category addressed before spending reviewer time on a broader implementation.

If maintainers are open to it, I think the clean path would be:

1. add failing tests for arrow expression bodies showing the invalid statement-position keywords,
2. introduce a narrower expression-position keyword filter,
3. keep block-body completions unchanged.

Happy to collaborate with you or compare findings if maintainers approve of it.

@danyalahmed1995 ,Thanks that matches my findings as well.

I ended up prototyping a narrowly scoped version locally to better understand the regression surface and completion flow, but I agree it makes sense to confirm maintainer appetite before moving further given the broader keyword-filtering implications and the repo’s maintenance policy.

The current prototype keeps block-bodied arrow completions unchanged and limits itself to concise arrow expression-body keyword filtering only.

Happy to pause on the PR path for now and wait for maintainer guidance.

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Similar Issues

Here are the most similar issues I found

• (66%) microsoft/typescript#61926: Fix local function variables being suggested in parameter defaults
• (65%) microsoft/typescript#16706: Incorrect completion offered for `export default` of named function/class

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

default cannot begin an expression, so suggesting it after the arrow—where only an expression is grammatically valid—looks like a genuine completion-list bug rather than correct compiler behavior.

[DhineshPonnarasan]

Thank you for the analysis! Since this is confirmed as a genuine completion-list bug, I'd like to ask: does this fix qualify for a maintenance-mode exception?

The change is:

• Scope: Narrowly-scoped keyword filtering (completions.ts only)
• Risk: Low filters out invalid keywords without changing any other behavior
• Impact: Improves UX by reducing noise in arrow function expression completions

It doesn't clearly fit categories 1-4 listed in the maintenance-mode policy, but the genuine bug nature and minimal scope suggest it might merit consideration. If this qualifies for an exception, I have a complete, tested implementation ready.

If not, I'm happy to redirect this work to the TypeScript-Go repository or document it for future contributors.

[snarbles2]

Since this is confirmed as a genuine completion-list bug

Just to be clear, a janky AI said this "appears" to be a genuine bug, immediately after saying that this behavior "might be intentional". I doubt this will be classified as a bug.

[RyanCavanaugh]

This is not going to meet the 6.0 patch bar. Does this repro in the TS 7 LS?

[DhineshPonnarasan]

I tried to test whether this reproduces in TypeScript 7, but TS 7 nightly is not yet available in the Playground. Could you provide guidance on how to test this in the TS 7 language service? Should I:

• Test in a local build of the typescript-go repository?
• Wait for TS 7 to be available in the Playground?
• Or is there another way to verify the bug in TS 7?

[MartinJohns]

@DhineshPonnarasan See: https://github.com/microsoft/typescript-go#preview

[DhineshPonnarasan]

Confirmed this reproduces in the TS 7 language service preview (typescript-go). Invalid statement-oriented keywords like default are still offered in expression-bodied arrow function completion.

See attached screenshot: the default keyword incorrectly appears as the first completion item in the expression-bodied arrow function position, where only expression-valid tokens should be suggested.

---