Forced to pass undefined when a method accepts void or undefined

[inad9300]

If a method accepts void as the type of one of its arguments, passing undefined to it should not be explicitly required, in my opinion, as the method will receive undefined anyway if no argument is provided.

My use case is as follows:

class C<T> {

    f(a: T) {}
}

const c = new C<void>() // Or: new C<undefined>()
c.f(undefined) // OK.
c.f() // Expected 1 arguments, but got 0.

Might be an uncommon case, but what I would like to effectively indicate from the the user of class C is the need or not to provide the argument a. In other words, the method f() of C should force you to send an argument to it if the type is different than void (so an optional argument doesn't work, unless there is a way to condition this to the argument type), but also allow you to say "I don't need an argument in f()" (and using a default type, e.g. any wouldn't be very type-safe, of course, so I would like to avoid this option).

What is the best possible way to achieve this for the time being? If none, does my proposal make sense?

[mhegazy]

I think void here is the wrong type. only use void in return type positions for functions to indicate the lack of a return value.

I think there is merit in general in allowing parameters that accept undefined to be skipped in a call under --strictNullChecks, in other words, treat f(a: number|undefined) as f(a?: number).

[inad9300]

I think you expressed it perfectly; that's it: T | undefined should be semantically equivalent to T?. And probably, if not under strict mode, T | undefined | null should be equivalent to T?.

[mhegazy]

No just T|undefined. Null has a different value.

[inad9300]

Well, you are the expert :)

[mhegazy]

looks like a duplicate of #12400

[inad9300]

So it seems indeed.

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.