Introduce 'extends type' and 'extends modifier' or phantom types to simplify the language and speed it up.

Basically when using [k in keyof] and mutating structures in ways that can be found at these repositories it becomes apparent that to simplify the learning cure it would be better if the type modifiers such as optional/required/undefined/readonly|null can be accessed and interrogated separately from the type and modifiers mashed together..
So one can focus on writing a routine that would iterate the type to be integorate for the architectural structure/shape if to call it that, which allow one to write super fast simple methods to recursively no the difference between Record<string,any>, Array, never, unknown. instead of having to do the following: T extends Record<string,any> | undefined | readonly | null ? then recuse, else step over.

The following type integogation operators.

1. extends ? mix of the type and modifiers
2. extends type ? just the base type without any modifiers (can only be single type else undefined)
   so string | number = undefined, string = string, number = number, array = array, record = record, class = class, constructor = constructor, one needs to be able to differential record, which is interface from Date so require have a phantom type if the interface was generate from a class or something the features a constructor. Otherwise one will iterate into custom types like Date, which is a problem.
3. extends modifiers ? Which just allows evaluation of modifiers. hopefully not a list in the backend implementation of the compiler code, hopefully just true and false flags for speed

Phantom types

Maybe just implement the concept of phantom symbols, that don't actually exists, were by optional/required, nullable, readonly, type can be access like :
T[PT.Required] extends true ? ..
T[PT.Nullable] extends true ? ...
T[PT.Readonly] extends true ? ...
T[PT.Type] extends true ? ...
T[PT.Cusom] extends true ? ... // For passing other information that doesn't exist to validate typings.
allow one to create the own phantom types, which information we will pass onto for downstream validation in some complex situations like Mongoose Update Statement validation which has 3 parts.

Work around Mongoose Update Statment

Work around Mongoose Types

https://github.com/Microsoft/TypeScript/issues/28699

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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Commencez par lire les opérateurs et le modèle de type fantôme proposés dans cette issue, puis comparez les exemples Mongoose liés et l’issue associée #28699. Identifiez les points d’entrée du compilateur TypeScript pour les types conditionnels et les modificateurs de type avant de définir le comportement attendu pour les unions, les records, les tableaux, les classes et les métadonnées fantômes personnalisées. Le travail est considéré comme terminé lorsqu’un design arrêté et les tests correspondants du compilateur sont disponibles.