Analysis support for metaprogramming decorators

## Search Terms decorator, metaprogramming, rename, renaming ## Suggestion As decorators near Stage 3, use cases are coming up that would currently pose problems for TypeScript due to their dynamic nature. Any additional properties added won't be visible, renamed properties won't analyze, and custom visibility schemes like protected or friends won't be understood. This is another area where the dynamic nature of JavaScript might stretch the TypeScript type system, but with mapped and conditional types we might be able to describe a subset of the use-cases in the type system. I don't have a concrete solution to suggest, but a couple of requirements that a solution should meet: - Describe the change in type of a decorated property - Describe the change in name of a property - Describe newly introduced properties (ie, private storage for an `@observed` property) - Describe changes to a class (ie, added static properties) Mapped and conditional types already support some type transformation, but not transforming the keys, or describing a transformation across the static and instance types. Maybe there's a way to expand on the list-comprehension-like syntax for mapped types to be even more like a list comprehension and allow - Transformations of property names - Filtering Here's a rough idea of a mapping that would transform a key name to a symbol, and filter by properties decorated with a specific decorator: ```ts type Namespaced<T> = { [Symbol(P): T[P] for P in keyof T where namespaced decorates P]; } ``` `Symbol(P)` and `where namespaced decorates P` are obviously very made up and probably not great choices choices. That's not exactly right for use from individual decorators though. Since decorators take and return an extended PropertyDescriptor, maybe we can just type the decorator itself: ```ts const namespaced = <P extends PropertyDescriptor>(descriptor: P): NamespacedPropertyDescriptor<P> => { ... } type NamespacedPropertyDescriptor<P extends PropertyDescriptor…