Skip to content

Suggestion about decorators #53411

Closed
Closed
@weiqj

Description

@weiqj

Suggestion

Relax syntax restrictions on decorations. At least do not remove parser support for decorators on interfaces.

I wouldn't mind parser-generated warnings because those can be suppressed. But if TypeScript stops parsing decorators on interfaces and interface members I will be really disappointed.

🔍 Search Terms

decorator syntax restriction interface

✅ 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

TypeScript works great as an "intermediate programming language", which is always transpiled into other languages.

Let's keep it that way! And make sure the design meets the requirements.

I would suggest TypeScript keep decorators on interfaces and interface members.

📃 Motivating Example

I am using TypeScript to transpile to Lua. And I need decorators on interfaces.

💻 Use Cases

Why can't decorators just "decorate"? It doesn't have to be meaningfully executable at all! After all, it is what meta-programming is about.

Metadata

Metadata

Assignees

No one assigned

    Labels

    DuplicateAn existing issue was already created

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions