The parameter of singal() can be omitted, just like useState().

[cnbebop]

Think about this, create a issue signal, and it's initial is undefined, then you should pass undefined to both generic parameter and function parameter.

const issue = signal<Issue | undefined>(undefined);

We can see that it leads to boilerplate code and the development experience is reduced.

The signal() can be defiened like this:

function signal<T>(value: T): Signal<T>;
function signal<T = undefined>(): Signal<T | undefined>;

[XantreDev]

I don't think it's a problem. Better to keep function with the same amount of arguments (it's better for performance)

[cnbebop]

I don't think it's a problem. Better to keep function with the same amount of arguments (it's better for performance)

Even if you're right, but the class Signal has an optional parameter constructor, how to explain it?

[rschristian]

Looks reasonable to me, if you want to PR it.

[XantreDev]

I don't think it's a problem. Better to keep function with the same amount of arguments (it's better for performance)

Even if you're right, but the class Signal has an optional parameter constructor, how to explain it?
It's not for public usage. But I see, probably it will think that it can have 0 params

signals/packages/core/src/index.ts

Line 531 in 58befba

Computed.prototype = new Signal() as Computed;

Anyway I think it should be benchmarked. Check for deoptimizations and how much it slows other benchmarks

[rschristian]

Anyway I think it should be benchmarked. Check for deoptimizations and how much it slows other benchmarks

This should be a type signature-only change. There will be no effect on the benchmarks

[JoviDeCroock]

@XantreGodlike This is in relation to an already allowed paradigm, signals can be initiated with undefined or a missing initializer as you yourself link to for the Computed.prototype. This can't possibly affect benchmarks as it's merely a change in how the generic infers the starting value.

[XantreDev]

It's not we are starting to provide interface that allows different amount of args. It can cause performance slow down, depending on usage
https://jsbench.me/7slty3mtij/1

[XantreDev]

But probably impact will be insignificant

[JoviDeCroock]

Did you read my comment? It's already ? allowed to be not there https://github.com/preactjs/signals/blob/main/packages/core/src/index.ts#L277

[rschristian]

It's not we are starting to provide interface that allows different amount of args

We are not. This usage has always been valid.

I don't think that benchmark is displaying what you think it is. Trying to do math with undefined is indeed going to be slower than adding two numbers together. This isn't going to be an issue here.

[XantreDev]

Did you read my comment? It's already ? allowed to be not there https://github.com/preactjs/signals/blob/main/packages/core/src/index.ts#L277

Got it. Sorry