Repository: TypeScript
Issue: [Feature Request] fieldof similar to keyof but include private and protected field
Labels: Suggestion,Awaiting More Feedback

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms
fieldof , mapped type, mapped private protected
Can maybe related: https://github.com/microsoft/TypeScript/issues/35416 https://github.com/microsoft/TypeScript/issues/4822

## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

add a new utility `fieldof` for map easily all keys field include, private and protected 

## 📃 Motivating Example
i have similar issue here where some pattern make complications !

```ts
type Writable<T> = { -readonly [P in keyof T]: T[P] }; // make writable A.parent for Childrable


class A {
  public readonly parent?: A
  protected Renderer() { };
}

// in this context, let say is a component added to A (plugin), with some method authorized to write on A.
class Childrable {
  public entity!: A;
  public readonly children: A[] = [];

  public addChild(...children: Writable<A>[]) {
    if (children.length > 1) {
      for (const child of children) this.addChild(child);
    } else {
      const child = children[0];

      if (child) {
        // So Writable<A> allow replace A.parent
        child.parent = this.entity;
        // But Writable<A> seem remove protected.Renderer prototype and now they are not compatible
        // I need allow replace A.parent and add A in Childrable.children in the same scope !
        this.children.push(child);
      }
    }

    return this;
  }
}
```
[playground](https://www.typescriptlang.org/play?#code/C4TwDgpgBA6gTgS2AQwEYBsIB4AqA+KAXigG8oBaOCZAEwHsA7dEKAbQAUoEGoBrCEHQBmUHAF0AXKI5ioAXwDcUAPTKoAW2T8oAd0QoM0AIIA6MMioNgUIXThQAwgAsE6GnDSYAsAChfvgGN0ZABnEKgjUl8oKDAAVwwEAKgqWkZmWIsIKwB+KSNo2Lg6YAgA0pooACVsmggqOAAKAEpSeV85fx8g0PDnV3dPaBJC+MTk7OAkEABCfIVRhPQklOp6JhYAlzdLfNZZYn2Fvx8YseXk2hp+t0aTe62B3dh9IawjPH3WkdOYrhFGo8dtkTJgGABzYBOKAEACM30KfxsdiggMYIWsQMqwigWMsrShCBCJiuNxogO2NGaxyRcigEHQIWGiL+AXRmMpRFxlMsrAADGJjiyYggAViEb8kTFVFAAMp0F5IN4fKDIdDoOg6VZgYIBYxmLJWYWsykGyzWYiE4mTaY0qXStQAITi1ngSsM7wITIg6lW6joADdoGBiqVyhAaCYagw6g0iiUSuBoMgY1AGJqoFCBKqqGmSri6OpzFNDMaHVAAJJpiAR1XqjNUHXIPURM2TVWpq4RLg8MkeQwmPHZHuZpzQELIdTjtmQKAzMujomDnkg+IhJwUgbU42dSXtE5IqjAOJwHhWu27uRAA)

It would be great to see a easy way to handle more patterns with `protected`, `private` fields when we map types for specific case.
In my upper example, `Childrable` is a component where you can attach to Entity `A` , and `Childrable` have some method where allowed to write in some `readOnly field` from A.
But map to readOnly will remove private and protected field and will create issue, in this case `fieldof` will fix the issue, becaue we want allow Writable<A>, in context of component have method for mutate entities.



<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

## 💻 Use Cases

```ts 
type Writable<T> = { -readonly [P in fieldof T]: T[P] }; 
```
So same as `keyof`, but include all `private` and `protected` fields for specific pattern.
This will also maybe unlock more powerful features and patterns, but let just talk about this specific case for now.

<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->