[reipahb]

I don't think programming languages implement decorators in order to facilitate type checking. They implement decorators because they are a nice generic way to reuse code in many functions / classes.

Now, once you have support for decorators, they can obviously be reused for type checking, but the linked repository also contains a few more decorators such as a memoization decorator.

I think those that add type checking decorators do so because it is a convenient way to add a some common code to multiple functions. The alternative for those that add decorators is to manually add a set of type checks in the beginning of each function.

Of course, if the language supported type checking they would simply use that, but if not, this is a simple way to save some lines of code.

[braythwayt]

  > I don't think programming languages implement decorators in order to facilitate
  > type checking. They implement decorators because they are a nice generic way to
  > reuse code in many functions / classes.

Well, in JavaScript, it’s particularly easy to write decorators as plain old JavaScript functions. Lots of libraries provide implementations that provide memoization or parameter checking on both functions and methods.

So in the short term, decorators serve only to work around the fact that ES-6 classes actually make this more difficult than ES-5 idioms.

But in the long term, a decorator can be extended to deal with static analysis, while functions provid eno such capability, so we’d be back to having “magic comments,” or inventing a new kind of pragma.

So, I’d say that the motivation is to lay the groundwork for things involving static analysis or manipulation of programs. Like type checking, or even manipulation of the AST.