I note also that the bug ticket mentions String(Object.getOwnPropertyDescriptor((function() { "use strict"; }).__proto__, "caller").get), which is especially interesting because that's actually a distinct area of web-reality cross-implementation spec nonconformance—every major browser presents unique functions for Function.prototype.{arguments,caller} {get,set} rather than the specified realm-singleton empty-[[InitialName]] %ThrowTypeError% that non-browser implementations correctly expose:

$ eshost -si function-prototype-accessor-names.js 
## Source
const initialNamePatt = /function\s*(?:\[")?([^(]*?)(?:"\])?\s*[(]/;
const manifestations = new Map();
for (const key of ["arguments", "caller"]) {
  const desc = Object.getOwnPropertyDescriptor(Function.prototype, key) || {};
  for (const kind of ["get", "set"]) {
    const fn = desc[kind];
    if (!fn) continue;
    const name = Function.prototype.toString.call(fn).match(initialNamePatt)?.[1];
    const reprName = `name=${name ? JSON.stringify(name) : "<empty string>"}`;
    if (!manifestations.has(fn)) manifestations.set(fn, [`name=${reprName}`]);
    manifestations.get(fn).push(`${key}{${kind}}`);
  }
}
for (const [_fn, paths] of manifestations) print(`${paths[0]} [${paths.slice(1)}]`);


#### engine262, GraalJS, LibJS, Moddable XS, QuickJS
name=name=<empty string> [arguments{get},arguments{set},caller{get},caller{set}]

#### JavaScriptCore, SpiderMonkey
name=name="arguments" [arguments{get}]
name=name="arguments" [arguments{set}]
name=name="caller" [caller{get}]
name=name="caller" [caller{set}]

#### V8
name=name="get arguments" [arguments{get}]
name=name="set arguments" [arguments{set}]
name=name="get caller" [caller{get}]
name=name="set caller" [caller{set}]

// input
class Foo {
  @reactive #bar = 123;
}

// output
let getBar, setBar, initBar;

class Foo {
  static {
    ({ get: getBar, set: setBar, init: initBar } = reactive(this)); 
  }

  #_bar = initBar(123);

  get #bar() {
    return getBar.call(this, this.#_bar);
  }

  set #bar(value: number) {
    this.#_bar = setBar.call(this, value);
  }
}

// input
class Foo {
  @reactive
  #bar() {
    return 123;
  }
}

// output if bar becomes a class field
class Foo {
  #bar = reactive(function () {
    return 123;
  })
}

// output if bar remains a method
let barDecorated;

class Foo {
  static {
    barDecorated = reactive(this, function() {
      return 123;
    });
  }


  #bar(arguments) {
     return barDecorated.call(this, arguments);
  }
}

class Fetcher {
  baseUrl = signal('https://api.example.com');

  fetch = reactiveMethod(this, async (path: Signal<string>) => {
    const response = await fetch(`${this.baseUrl.value}${path.value}`);
    return response.json();
  });
}

Decorator metadata is still different from annotations though, and its more like defining a blessed extra property to share information between decorators. It allows for ergonomics vs not having them:

// with annotations

// NOTE: A and B can coordinate using metadata
@A
class C1 {
  @B
  method() {}
}

// NOTE: metadata is unique to each class
@A
class C2 {
  @B
  method() {}
}

// without metadata
const { A: A1, B: B1 } = createEntagledDecorators();

@A1
class C1 {
  @B1
  method() {}
}

// NOTE: needs new entangled instance
const { A: A2, B: B2 } = createEntagledDecorators();

@A2
class C2 {
  @B2
  method() {}
}

even the stage 1 spec allowed people to add additional fields/methods easily, and when I really stepped back I understood that was really bad for DX because of the magic. Like, people could do:

class Foo {
  @reactive
  bar = 123;
}

let foo = new Foo();

foo.setBar(456);

they can't be compiled efficiently

I think we should designing features that don't cause mass user harm.

• filter
• names
• only
• ...?

fwiw, I think you could argue that features like closures cause mass user harm with this logic, and by extension promises/futures. There is a logic to this, for sure. But at the same time, I think that the complexity of futures/promises is worth it because of how complex traditional callbacks are.

Bringing it back to decorators and async-context, this is what I'm exploring with "reactive functions". You can think of a signals + reactive functions as analogous to an promises + async functions.

• Async functions capture the execution context (e.g. the current variables in scope, the location of the program counter) and through that, know when and how to resume the function later.
• Reactive functions capture the reactive context (e.g. the dependencies of the current function instance) and through that, know when and how to automatically re-execute and stay up to date.

So far, I'm finding these really simplify reactive code and make common, complex, and error-prone tasks much safer. But, they rely on implicit context (to gather the dependencies during execution) and decoration (to annotate the functions).