Accessors should be allowed to be optional

Suggestion

Right now accessors are barred from being declared optional. This is a DX regression for decorator users.

🔍 Search Terms

accessor optional

✅ 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

Allow accessors to be declared options;

📃 Motivating Example

Decorating a class field should require as few changes over a non-decorated field as necessary. Disallowing accessors from being optional adds an additional change.

Take a plain class:

class A {
  foo?: number;
}

Where you then want to make foo reactive with some library that vends decorators. This would be the change I would expect to make:

import {reactive, Base} from 'some-reactivity-lib';

class A extends Base {
  @reactive
  accessor foo?: number;
}

But 5.0 requires:

import {reactive, Base} from 'some-reactivity-lib';

class A extends Base {
  @reactive
  accessor foo: number | undefined;
}

I don't see a semantic problem with optional accessors. They behave very similar to optional fields (with standard field semantics). With useDefineForClassFields and this example:

class C {
  accessor foo?: number;
  
  bar?: number;
}

both foo and bar would exist on the runtime object even though they're optional, ie 'foo' in c === 'bar' in c.

💻 Use Cases

More ergonomic decorator usage.

Es werden keine Quelldateien, Tests oder Einstiegspunkte genannt. Beginne damit, die Beispiele für optionale Felder und optionale Accessors in einem TypeScript-Testfall nachzustellen, und vergleiche anschließend das Verhalten bei der Typprüfung sowie das emittierte/Runtime-Verhalten mit den im Issue genannten Erwartungen. Fertig ist die Aufgabe, wenn optionale Accessors akzeptiert werden, ohne eine explizite undefined-Union zu erfordern, und das bestehende Verhalten unverändert bleibt.