Proposal built-in decorator @decorator

[silkentrance]

In TypeScript there is a so-called ambient decorator, or at least it was proposed, called @decorator.

Having this built-in decorator allows the user, aka developer of decorators, to make it clear for the transpiler that the free function is to be used as a decorator.

This would allow the system to apply extra validation during transpile, and maybe also to perform additional transformations. In addition it will make the code much more understandable in case the developer did not document the function.

This might help in realizing either #62 or even #65 or an altogether different approach, solving the seemingly unsolvable issue #23.

E.g.

@decorator({parameterized:true|default false})
function decorator() {...}

Alternatively, one could use, and which would be far easier

@decorator[.parameterized]
function decorator() {...}

The transpiler will then have knowledge on whether the original author of the decorator is expecting additional, possibly even optional, parameters. This then could be used by the transpiler to generate different code upon the actual use of the decorator, or even bail out if said parameters are not optional, e.g.

@decorator.parameterized.required
function decorator() {...}

[silkentrance]

Forget this one, I was drifting off. This requires additional meta data that the ECMAScript standard cannot provide for and is entirely implementation specific.