TypeScript Bot (@typescript-bot) perf test
TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this

Heya Ron Buckton (@rbuckton), I've started to run the diff-based user code test suite on this PR at b3487dc. You can monitor the build here.

Heya Ron Buckton (@rbuckton), I've started to run the parallelized Definitely Typed test suite on this PR at b3487dc. You can monitor the build here.

Heya Ron Buckton (@rbuckton), I've started to run the extended test suite on this PR at b3487dc. You can monitor the build here.

Heya Ron Buckton (@rbuckton), I've started to run the perf test suite on this PR at b3487dc. You can monitor the build here.

TypeScript Bot (@typescript-bot) perf test

Heya Ron Buckton (@rbuckton), I've started to run the perf test suite on this PR at a37f09a. You can monitor the build here.

Update: The results are in!

Ron Buckton (@rbuckton)
The results of the perf run you requested are in!

Comparison Report - main..49705

Download Benchmark

TypeScript Bot (@typescript-bot) run dt
TypeScript Bot (@typescript-bot) test this
TypeScript Bot (@typescript-bot) user test this

Heya Ron Buckton (@rbuckton), I've started to run the parallelized Definitely Typed test suite on this PR at 54024cf. You can monitor the build here.

Heya Ron Buckton (@rbuckton), I've started to run the diff-based user code test suite on this PR at 54024cf. You can monitor the build here.

Update: The results are in!

Heya Ron Buckton (@rbuckton), I've started to run the extended test suite on this PR at 54024cf. You can monitor the build here.

Heya Ron Buckton (@rbuckton), I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here.

Ron Buckton (@rbuckton)
Great news! no new errors were found between main..refs/pull/49705/merge

Why is this a thing? Like, what problem does it actually solve (genuine question, not snark)? The generated accessors don't do anything and unlike, e.g., C#, changing a plain property to an accessor isn't generally an API break...

edit: Oh, I see, it's mostly because decorators will apparently make a distinction between field and accessor.

Why is this a thing? Like, what problem does it actually solve (genuine question, not snark)? The generated accessors don't do anything and unlike, e.g., C#, changing a plain property to an accessor isn't generally an API break...

edit: Oh, I see, it's mostly because decorators will apparently make a distinction between field and accessor.

This was a requirement from VM implementers to avoid the potential hidden shape changes that could occur if you were able to convert a field declaration into an accessor dynamically rather than statically. It also helps to avoid issues with public field shadowing in cases like the following, such as with @observe in #48814:

class C {
  // observe attaches an accessor pair to C.prototype, but the field `x` is defined
  // on the instance, shadowing the accessor pair.
  @observe x = 1;
}

// vs
class C {
  // observe can now instead intercept the `{ get, set }` provided to attach its behavior.
  @observe accessor x = 1;
}

What are the assignability rules for auto-accessor fields? I guess that they're the same as a normal class field, but might be missing something.

They should be treated the same as we would a get/set pair.

Ah, that explains why the code in the checker is with the existing accessor code, not the property declaration code.

Very naive question:
Is there a reason not to implement a similar keyword for public readonly properties which would do the same, but without a setter?

EDIT: I guess the keyword for readonly properties would be readonly :)
First thought is, the transpiler could, if target > ES2015, transform

class C {
    readonly x = 1;
}

into

class C {
    #x_accessor_storage = 1;
    get x() { return this.#x_accessor_storage; }
}

But that would be a very breaking change; which could be enabled by a --strictReadonly flag in the compiler options... Which would be a lot of work just for syntactic sugar

Is there a reason not to implement a similar keyword for public readonly properties which would do the same, but without a setter?

More generally, is there a reason that readonly accessor isn't supported?

Is there a reason not to implement a similar keyword for public readonly properties which would do the same, but without a setter?

More generally, is there a reason that readonly accessor isn't supported?

It's not currently supported because the accessor isn't actually read-only (a setter is still generated) and that might break user expectations. Also, support for actual read-only accessors is planned as part of https://github.com/tc39/proposal-grouped-and-auto-accessors, which is blocked on any advancement until after Decorators reaches Stage 4.

With the full auto-accessors proposal, you could accomplish a true read-only accessor using the following syntax:

class C {
  accessor x { get; } = 1;
}

Which would transform into something like this:

class C {
    #x_accessor_storage = 1;
    get x() { return this.#x_accessor_storage; }
}

Actually having a readonly accessor x; would be lovely to just generate the public getter ❤️