Joe Pea

> While we can't change the order, and doing so would break _other_ use cases (like `@bound`) @justinfagnani *some* issue with `@bound` I think exists either way, with current ordering,...

With all that being said, I thought of another proposal that solves the current ordering issues, without changing the current design (i.e. an addon to the current design): # Solution...

# more workarounds/alternatives Another approach is to take advantage of the fact that in JS we can detect arity, and just rely on function values instead of clean settable fields....

That's a solid opinion! I'm talking about *writable* memos in the OP. `sum = this.a + this.b` is a fine that semantic because the field is both read/write. The signals-utils...

For `signals-utils` I'd rename that to `@computed get sum() {}` to align with the proposal naming, because Signals are writable.

> If I understand correctly they're something of a combination of a computed and state signal. Yes indeed. They're easy to express as simply the latest value from two signals:...

If the decorators ran in the intuitive expected order, I'd have a very simple workaround for - https://github.com/tc39/proposal-decorators/issues/565 The solution would be to track the decorated members to a Set/Map...

I was able to make it work out using the ordering trick of my previous comment. - [`@signal` decorator](https://github.com/lume/classy-solid/blob/93371ff4142f7f1919b6a9fb1714c86a4fd4bf21/src/decorators/signal.ts#L43-L80) (only the `kind === 'field'` part is relevant for the example)...

A possible solution: - https://github.com/tc39/proposal-decorators/issues/574