Creating two categories of parameter lists

[jamiebuilds]

Since this proposal is only for class methods, it would split "parameter lists" as a syntax up into two new categories, creating more confusion for users and more complexity for parsers/etc.

// SyntaxError!
function foo(@MinLength(0) param) {
  // ...
}

let obj = {
  // SyntaxError!
  foo(@MinLength(0) param) {
    // ...
  }
}

class Obj {
  // Ok
  foo(@MinLength(0) param) {
    // ...
  }

  // SyntaxError!
  #foo = (@MinLength(0) param) => {
    // ...
  }
}

Parameter lists are already a very dense syntax space, even more so with type annotations. It's unfortunate that this would add more complexity.

[rbuckton]

Since this proposal is only for class methods, it would split "parameter lists" as a syntax up into two new categories, [...]

This is already the case for method decorators, which are only allowed on class methods. As I've stated in the explainer, I fully intend to extend this solution to object literal methods, arrow functions, and function declarations and expressions in the future. Function decorators were considered in the initial decorators proposal, but were postponed to a follow-on given the complexities caused by function declaration hoisting.

IIRC, class method decorators were prioritized over object literal methods for proposal scope reasons. It's far easier (and more semantically equivalent) to do { f: wrapper1(wrapper2(function() {})) } today than it is with classes.

I've chosen to prioritize parameter decorators over function decorators as there is an existing user base of TypeScript users that use class method/constructor parameter decorators today that would like to be able to migrate to native decorators, and it's important to know whether this is a feature TC39 will adopt.

While I strongly believe that function decorators and object literal method decorators should be pursued in the future, we don't have anywhere near the amount of evidence about adoption that we do for parameter decorators today.

[...] creating more confusion for users and more complexity for parsers/etc.

If a parser already supports the existing stage 3 Decorators proposal, then supporting parameters isn't complex. This proposal would reuse the existing DecoratorList production, so much of that complexity will already be handled. Babel's parser already supports parsing parameter decorators, which means many existing tools in the ecosystem already have the potential to recognize the syntax. Parameter decorators are also already supported in deno.

Parameter lists are already a very dense syntax space, even more so with type annotations. It's unfortunate that this would add more complexity.

Parameter decorators are widely used in TypeScript, which has both. There may be an argument to be made for repetition in some TypeScript code bases, such as this example from VS Code:

export class ExtensionManagementService {
  constructor(
    @IExtensionGalleryService galleryService: IExtensionGalleryService,
    @ITelemetryService telemetryService: ITelemetryService,
    ...
  ) {
    ...
  }
}

However, this is actually a limitation of TypeScript's inference logic that we plan to address in the near future.

[jamiebuilds]

Parameter lists are already a very dense syntax space, even more so with type annotations. It's unfortunate that this would add more complexity.

You're focusing entirely on the uninteresting (easy) part of this complexity: parsers, and not on the overhead imposed on every JavaScript user, and on the long tail of tools that are built on top of these parsers.

constructor<M, N extends O>(@x @y() { a = b }: C = c, @z d?: D, ...f: F[]): M {...}

This example is not to demonstrate realistic code anyone would ever write, but the mental model of syntax intersections that every JavaScript developer would need to learn (assuming use of type annotations given its an active proposal further along in the process).

[rbuckton]

Your example illustrates a particularly degenerate case, and its fairly easy to craft a degenerate case for almost any aspect of JavaScript. TypeScript has had support for Parameter Decorators for over 7 years, and such cases are exceedingly rare.

This example is not to demonstrate realistic code anyone would ever write, but the mental model of syntax intersections that every JavaScript developer would need to learn (assuming use of type annotations given its an active proposal further along in the process).

Yes, syntax like this requires additional cognitive overhead to process, but most examples in the wild today aren't so complex as to be unreadable given a general understanding of decorators. The explainer has multiple links to SourceGraph searches of codebases on GitHub using parameter decorators, employing precisely the same combination of concepts you are describing (decorators + type annotations). Parameter decorators aren't often used to such an extreme as to be unreasonable, but are often used to great effect to concisely layer new capabilities on top of existing code.