Type annotations as metadata in decorators

[jithujoshyjy]

This is might sound like a cross over proposal between this one and the decorators proposal. But I guess once the decorators proposal reaches stage 4 this could be added as an extension.

Maybe something like:

@tscheck
function greet(word: string) {
    return word + " world!"
}

@tscheck
let word: string = greet("hello")

and to a decorator the meta data would look like:

type Decorator = (value: Input, context: {
  kind: string;
  name: string | symbol;
  access: {
    get?(): unknown;
    set?(value: unknown): void;
  };
  typeHint: string;
  isPrivate?: boolean;
  isStatic?: boolean;
  addInitializer?(initializer: () => void): void;
}) => Output | void;

If there is no type information available, the typeHint field would be an empty string or null or undefined or whatever, you get the point.
This would mean that decorators should also be allowed to work with variable declarations and loops and literally everything else that is typeable😅
This also means that we could leave the type checking to the end user/library code (typing semantics defined by the user not by the language).
Where in a perfect world I would imagine having a boolean global/environment variable which could be set to true during development - enabling type checking and turning it to false during production.
This might not help with Interfaces, Enums; i.e if they don't have any runtime sematics. Python decorators have the capability to do this sort of checks, correct me if I'm wrong!

[Hookyns]

It would be nice to have such metadata provided by JS runtime, but it is not real IMHO; even TS don't want to do that so we created https://github.com/Hookyns/tst-reflect

[matthew-dean]

@jithujoshyjy What do you think of this proposal? https://github.com/matthew-dean/proposal-annotations

[jithujoshyjy]

It would be nice if type annotations were also accessible through Symbol.annotations.
But how would it work for variables, constants, or stuff other than functions. Currently decorators only support classes and class fields. I'm hoping they would support other language structures after they are introduced.

[matthew-dean]

@jithujoshyjy Discussion for this proposal has been added to: tc39/proposal-decorator-metadata#11

But how would it work for variables, constants, or stuff other than functions.

The decorators group already has a proposal for this! Please read: https://github.com/tc39/proposal-decorators/blob/master/EXTENSIONS.md

The short answer is that values get converted into an object with a getter, setter, (internal) value, and, of course, a metadata (or annotations) key.