Decorator lazy evaluation for function declaration

[hax]

Let's continue the discussion here.

[hax]

copy from @hax 's comment: tc39/proposal-decorators#40 (comment)

---

The best solution for the hoisting problem I can imagine is transform

@deco function f() {
  funcBody
}

to

function f(...args) {
  $do_decorate_f()
  return $decorated_f.call(this, ...args)
}
var $decorated_f
function $do_decorate_f() {
  if (!$decorated_f) $decorated_f = deco(function f() {
    funcBody
  })
}
$do_decorate_f()

Aka, not hoist the execution of decorator until first call.

[hax]

copy from @rbuckton 's comment: tc39/proposal-decorators#40 (comment)

---

@hax, your example only works if the decorator deals with the function's execution, but not if the decorator augments the function object itself.

My opinion is that decorating a function declaration should transform it into something like this:

var f = @deco function() {
  funcBody
}

However that means adding a decorator to a function might mean needing to move the entire function around in your code if you were depending on function declaration hoisting.

Another possibility is to introduce block-scoped function declaration syntax like this:

let function f() {}
const function g() {}

And then only permitting decorators on a block-scoped function declaration. It still requires moving the function, but it is visually consistent with block-scoped variable declarations.

A third option would be to make decorator evaluation lazy and apply it at one of two times (whichever comes first):

When the function declaration is encountered during evaluation,
The first time the function declaration is accessed as a value.
The closest approximation of this approach in existing code would be this:

let g = f; // access f before declaration
f(); // invoke f before declaration

@deco function f() {
  f(); // invoke f inside of declaration
}

Becomes:

let g = $$f_accessor(); // access f before declaration
(void 0, $$f_accessor())(); // invoke f inside of declaration

function f() {
  f(); // invoke f inside of declaration
}
var $$f_decorated;
function $$f_accessor() {
  return $$f_decorated || ($$f_decorated = f = deco(f));
}
$$f_accessor(); // eval decorator if not already accessed

[hax]

Copy from @trotyl 's comment tc39/proposal-decorators#40 (comment)

---

@rbuckton The third option won't work with circular dependency in ES module.

Given the scenario:

// main.mjs
import './f';

// f.mjs
import { g } from './g';

export function f ( x ) {
  return x + 1;
}

console.log(g(1));

// g.mjs
import { f } from './f';

export function g(x) {
  return x - 1;
}

console.log(f(1));

Which should output 2 and 0;

When decorating f with some decorator:

// f.mjs
import { g } from './g';

function deco(fn) {
  return function (x) {
    return fn(x) + 100;
  }
}

export @deco function f ( x ) {
  return x + 1;
}

console.log(g(1));

Option a): still exports f itself:

// ...
export function f ( x ) {
  return x + 1;
}

var $$f_decorated;
function $$f_accessor() {
  return $$f_decorated || ($$f_decorated = f = deco(f));
}
$$f_accessor();

console.log(g(1));

Then undecorated original function gets called.

Option b): exports the decorated one:

// ...
function f ( x ) {
  return x + 1;
}

var $$f_decorated;
export { $$f_decorated as f }
function $$f_accessor() {
  return $$f_decorated || ($$f_decorated = f = deco(f));
}
$$f_accessor();

console.log(g(1));

Then it would throw due to calling undefined: TypeError: f is not a function.

Option c): exports the accessor call result:

// ...
function f ( x ) {
  return x + 1;
}

var $$f_decorated;
function $$f_accessor() {
  return $$f_decorated || ($$f_decorated = f = deco(f));
}
var $$f_accessor_export = $$f_accessor();
export { $$f_accessor_export as f }

console.log(g(1));

Also got undefined and throws as above.

---

So there's still no way to keep the behavior consistent between decorated and undecorated functions. The result becomes:

The decorated function would be hoisted in most cases, but not hoisted in some special cases

That's a pretty bad idea for consistency.

Also, making decorator affects execution of dependent files would break current module semantics, and making transformer depends on external files could be very complex (if possible) and cannot help with libraries.

One solution could be waiting for https://github.com/tc39/proposal-module-get lands first.

Not possible even with that landed.

[hax]

@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).

With https://github.com/tc39/proposal-module-get you refer to, it's possible to transform the @deco export f() {...} to

...
export get f() { return $$f_accessor() }
...

Without export get extension, it's hard to transform it to ES2015 module, but it's possible to transform it to CommonJS.

Note: The other option is use Proxy to wrap f, but I'm not sure whether it will introduce other problem.

Anyway, there are the difficulties of polyfills, not for engines.

[rbuckton]

Option 3 is not really viable, because it falls apart even without modules:

function deco() { f(); }
@deco function f() {}

If we did go with Option 3, we'd still need Option 1 for the recursive reference case, or we'd get a stack overflow. In the case of recursive dependencies between modules, we'd still need Option 1.

At the end of the day, it seems only one of three scenarios make sense:

1. While decorators could be allowed on FunctionExpression, they can never be permitted on FunctionDeclaration. To decorate a FunctionDeclaration you would need to rewrite it as a FunctionExpression.
2. Decorating a FunctionDeclaration gives it TDZ like let/const.
3. (2), but with some kind of syntactic mark that makes it clear it has let/const-like semantics (my Option 2 above).

If we choose (1) the fact we cannot decorate function declarations will likely come up again and again as it is inconsistent with the ability to decorate classes and function expressions. If we choose (2) we would have to convince the rest of TC39 that it is worth expanding TDZ to this case, but we would have the consistency across these declarations hopefully without needing to revisit the decision. If we choose (3) we have to defend the syntactic marker.

Are there any other scenarios that make sense that I'm missing?

[trotyl]

@hax The module getter won't be hoisted as well, consider:

let foo = 42;
export get f() { return foo; }

It will be an early error when accessing foo before the declaration.

Even transpiled to:

Object.defineProperty(module, 'f', {
  get() { ... }
}

This is still a statement and won't be executed at that time.

[hax]

@rbuckton Oh I never thought about recursive... What happen for class decorator?

// deco.js
import {A} from './a'
export function deco() {
  new A() // <- call undecorated A ?
}
// a.js
import {deco} from './deco'
@deco
export class A {}

If the behavior is return original undecorated A, I think we can just do a little adjustment to deal with reenter like:

var $$f_decorating, $$f_decorated;
function $$f_accessor() {
  if (!$$f_decorated) {
    if ($$f_decorating) return f
    $$f_decorating = true
    f = deco(f);
    $$f_decorated = true
  }
  return f;
}

[hax]

@trotyl What I mean is using export get to export f like this:

export get f() { return f_accessor() }

I assume export get f hosited same as export function f.
And f_accessor as function decl is hoisted, so it works.

[rbuckton]

@hax, classes have a TDZ and the declaration isn't yet initialized when the decorator is called, so you would get a runtime error. This is not the case with functions.

[iddan]

Have you considered to limit this proposal to instead of introducing new syntax?

@bar
const foo = () =>

[iddan]

I created a transpiling PR (#2) so hoisting ideas can be tested in the wild.
Would you like to merge the basic transpiling for now? Or to limit it to var func = expressions?

[hax]

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

[hax]

@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 confusion when they finally try decorate plain old functions.

We all know hoisting is troublesome, even without decorator, you may meet some bug caused by a hoisting function accessing a variable in TDZ or uninitialized state. But in most cases, it works. I don't see much difference with addition of decorator. When ES2015 introduce modules, it also keep the hoisting semantic. Note, without hoisting function declarations, there is no reason to support circular dependency modules because you will just get TDZ or undefined. The designers of ES modules put effort to support hoisting semantic of function semantic. So should we do.

I believe the direction of lazy evaluation is promising (or maybe Mirror,though I haven't figured it out now, hope @rbuckton could have time to explain how it work). We just need to get a reasonable behavior for most cases, and leave edge cases as is (just like throw runtime Error for TDZ).