New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameter decorators #1301

okunokentaro opened this Issue Apr 20, 2015 · 11 comments


None yet
9 participants
Copy link

okunokentaro commented Apr 20, 2015


in TypeScript 1.5 Alpha.

// foo.ts
function Parent(...args: any[]) {
  console.log('Parent args', args);
  return (...args: any[]) => {
    console.log('cb args', args);
    return args[0];

class Clazz {
  A: any;
  B: any;
  constructor(@Parent(123) A: any, @Parent(456) B: any) {
    this.A = A;
    this.B = B;

var a = new Clazz('foo', 'bar');

It's a result.

$node foo.js
Parent args [ 123 ]
cb args [ [Function: Clazz], undefined, 0 ]
Parent args [ 456 ]
cb args [ [Function: Clazz], undefined, 1 ]
{ A: 'foo', B: 'bar' }

Currently (5.1.10) Babel cannot parse @ in this position.

babel /Users/armorik83/Desktop/foo.es6 --optional es7.decorators
    throw err;
SyntaxError: /Users/armorik83/Desktop/foo.es6: Unexpected token (12:14)
  10 |   A: any;
  11 |   B: any;
> 12 |   constructor(@Parent(123) A: any, @Parent(456) B: any) {
     |               ^
  13 |     this.A = A;
  14 |     this.B = B;
  15 |   }



This comment has been minimized.

Copy link

shuhei commented Apr 20, 2015

One thing to note here is that decorating function formal parameters is currently not part of the ES7 proposal. You can check out the proposals here.

@kittens kittens changed the title Decoration to class constructor's arguments Parameter decorators Apr 20, 2015


This comment has been minimized.

Copy link

kittens commented Apr 20, 2015

This isn't included in the ES7 proposal and TypeScript have added it by themselves. I think this is extremely dangerous and they're going to fuck over their users as the spec is in extreme flux and semantics are changing. Adding an unspecced and highly controversial decorator extension is going to cause pain.

@kittens kittens closed this Apr 20, 2015


This comment has been minimized.

Copy link

okunokentaro commented Apr 20, 2015

well, I agree.


This comment has been minimized.

Copy link

IgorMinar commented Aug 19, 2015

This feature is part of the ES proposal, as presented and discussed during May's TC39 meeting. See:

Can we get this issue reopened please?

@kittens kittens reopened this Aug 19, 2015


This comment has been minimized.

Copy link

mgcrea commented Aug 21, 2015

Does it mean that #2138 would be acceptable as a stage 0 feature?


This comment has been minimized.

Copy link

jamiebuilds commented Aug 29, 2015

What's mentioned in isn't really a proposal. I'm still hoping there will be something formal written up. Until that happens it's not going to end up on

cc @IgorMinar @bradlygreen @mhevery


This comment has been minimized.

Copy link

gionkunz commented Sep 12, 2015

There doesn't seem to be an agreement on this at all if I look at the meeting protocol specially when it comes to the scope and dynamic nature of function parameters. There are no decorators for functions because of the hoisting issues. Currently frameworks work around this by using property decorators and effectively treat them as class method decorators (which when writing them also seems right), but effectively they are just property decorators. As long as there are no real function decorators, there won't be any function parameter decorators.

Constructors can't have decorators in the ES7 decorator proposal as they don't get defined as object properties and classes can only have decorators because the resulting constructor function is not hoisted. This is already confusing but after reading all those threads, the limitations seem to be quite hard and all pointing back to the hoisting issues.

Let's say, just hypothetically, that TC39 agrees on the "workaround" of treating all functions with decorators on them as function expressions and don't hoist them. Then there would possibly be a solution where function and function parameter decorators could exist. However, there will be a conflict with property descriptors I guess, because how would JavaScript know if you're defining a function decorator or a property decorator when a function is defined inside a class? Maybe the short hand class { @A() a() {} } could assume function level decorators and class { @A() a: function() {} } would assume class property level? Still not very clean I guess.

I wonder how TypeScript implemented this? I'm still trying to keep things pure ECMAScript but having function and function parameter decorators is just really nice for framework API design and tooling support. I really hope that there's a super brain somewhere who finds a good solution for this issue.


This comment has been minimized.

Copy link

jamiebuilds commented Sep 23, 2015

I spoke to @jonathandturner about this. According to him, the tc39 decided decorators are going to be in two chunks. Chunk 1 is classes, class members, and maybe class properties. Chunk 2 is parameter decorators, maybe function decorators, etc. which likely needs more work in the reflection system.

I say it's too early to be talking about this. I also haven't heard much interest outside of the Angular team so I'm bearish on this ever being part of the standard.

Closing as wontfix for now. Contribs feel free to reopen.

@jamiebuilds jamiebuilds added the wontfix label Sep 23, 2015

@babel-bot babel-bot reopened this Sep 7, 2016


This comment has been minimized.

Copy link

babel-bot commented Sep 7, 2016

Comment originally made by @IgorMinar on 2016-02-02T17:35:41.000Z

Param decorators proposal has been accepted by TC39 a few days ago and are at stage 0 now: tc39/ecma262#323

Comment originally made by @shuhei on 2016-02-19T15:52:18.000Z

[[ | The stage 0 proposal]] doesn't specify how parameter decorators should work but it shows the syntax.

Is it acceptable to add only parser support first and implement appropriate transform when the proposal becomes implementable? If only babylon parses the syntax, people can start building transform plugins, like Angular 2 annotation, on top of it.

Comment originally made by @IgorMinar on 2016-02-20T00:52:14.000Z

@shuhei the actual transform is still being debated. TypeScript implements one, but I expect that it will still change. Ron Buckton from MS has a Mirrors proposal which seems like the best way forward for this as well as several other decorator related transforms so we will most likely end up heading in that direction.

In the meantime I think that implementing the parser support and making it possible to implement the actual transform via a plugin like yours would be the most preferable solution.

We want the babel users to be able to use this syntax with Angular apps while shielding them from the underlying implementation that we'll tweak as spec matures.

@hzoo hzoo added the es-proposal label Oct 15, 2016

@hzoo hzoo added Priority: High and removed Priority: High labels Mar 20, 2017


This comment has been minimized.

Copy link

hzoo commented Jul 21, 2017

@babel-bot move to babel/proposals

@hzoo hzoo closed this Jul 21, 2017


This comment has been minimized.

Copy link

babel-bot commented Jul 21, 2017

Hey @armorik83! I've moved your issue to the correct repository. Please make sure to keep an eye on the new issue for the latest information.

@babel-bot babel-bot referenced this issue Jul 21, 2017


Parameter Decorators (Stage 0) #13

0 of 1 task complete

@lock lock bot added the outdated label May 4, 2018

@lock lock bot locked as resolved and limited conversation to collaborators May 4, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.