HE Shi-Jun

@trotyl The whole idea is eval decorator lazily when first access `f` whenever locally or in other modules, that means what need to export is `$$f_accessor()` call pattern (not result)....

@rbuckton Oh I never thought about recursive... What happen for class decorator? ```js // deco.js import {A} from './a' export function deco() { new A() //

@trotyl What I mean is using export get to export f like this: ```js export get f() { return f_accessor() } ``` I assume `export get f` hosited same as...

@rbuckton Ok, so we could also throw similar runtime error when meet reenter?

@iddan I think the keypoint is, if we allow decorate arrow functions, function expressions, or even some new syntax, but not function declaration, it just make programmer get much more...

The transpiling of decorating function declarations may be a problem, because we rely on `export get f() {}` and assume it hosit same as `export function f() {}`. Or we...

> Would decorators only be processed when the function is called? My second comment https://github.com/iddan/proposal-function-expression-decorators/issues/3#issuecomment-370198619 use this strategy. But @rbuckton is right, it should be the first time of function...

@Alphare Sorry I don't get it, could you give a example code?

> As long as they're not used in top-level (module initialization), it makes no difference whether hoisted or not. @trotyl U r correct. But in that time (pre ES6), there...

@trotyl Good example. But I don't see use cases for supporting computed property for `export get`. Normal getter/setter need it, mainly because we need to support access symbol property or...