Repository navigation
Distinguish missing and undefined also in arguments #44548
Description
Suggestion
With the arrival of --strictOptionalProperties, it’s clear that the intent of ? as a modifier isn’t to add | undefined to the type but to distinguish presence from absence.
I propose the same should apply to arguments.
🔍 Search Terms
optional argument, optional arguments, optional parameter, optional parameters
✅ Viability Checklist
My suggestion meets these guidelines:
- This wouldn't be a breaking change in existing TypeScript/JavaScript code (unless behind a flag)
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.
⭐ Suggestion
Given
function optionallyTakesAnArg(arg? : string) {
return arguments.length;
}calling optionallyTakesAnArg() is not the same as optionallyTakesAnArg(undefined). TypeScript should be able to model this. Specifically it should forbid the second form and only allow either optionallyTakesAnArg() or optionallyTakesAnArg(stringArg).
📃 Motivating Example
This is mostly an issue when the argument is a generic type that may or may not include an explicit undefined:
function optionallyTakesAnArg<T>(arg? : T) {
if(arguments.length > 0) {
// arg passed, do stuff
doStuffWith(arg!);
} else {
// no arg passed, do something else
doOtherStuff();
}
}💻 Use Cases
I want to model that calling optionallyTakesAnArg<string>() and optionallyTakesAnArg<string>(stringArg) both are valid but that optionallyTakesAnArg<string>(undefined) is not, whereas optionallyTakesAnArg<undefined>() and optionallyTakesAnArg<undefined>(undefined) are (but may not do the same thing).
Further, overloads should be able to distinguish between the latter two cases, e.g. for inference of return types.
This allows arguments whose type is a generic that may include undefined to be modeled correctly.
⚡️ Open issues
- Arrow functions don’t have an arguments object in scope so the only way to implement this would be with rest params and tuples, which means they, too, would need new semantics for
?. - This proposal is at odds with default arguments which always treat absent and undefined the same (
(function(a = 1) { return a })()and(function(a = 1) { return a })(undefined)both evaluate to1). - It’s also possible to model optional args using
optionallyTakesAnArg(arg : string | void), which, AFAICT currently has the same semantics asoptionallyTakesAnArg(arg? : string). I’m not sure whether this should continue to be aligned or not.
Activity
RyanCavanaugh commentedon Jun 11, 2021
This was discussed quite a bit when we were making
strictOptionalPropertiesand we weren't really enthusiastic about it. In addition to the problems you noted, non-trailingundefinedsare not even possibly-detectable, so there isn't a runtime behavior to map this on to except in terminal argument positions.KageShiron commentedon Jun 24, 2021
Ryan Cavanaugh (@RyanCavanaugh)
Where can I find that discussion?
I would like to make it an error to be able to specify undefined for an argument with default parameter, similar to this suggestion. This looks to be an unnatural behavior.
Or should I suggest this to typescript-eslint?
RyanCavanaugh commentedon Jun 24, 2021
It was in a meeting.
Passing
undefinedto a parameter with a default seems very unproblematic and I don't see us banning it under any circumstance. If the function didn't want someone passing an explicitundefined, they shouldn't have put a default in the parameter position.KageShiron commentedon Jun 24, 2021
I got it, thanks!
zyf0330 commentedon Oct 13, 2021
Hello, I have a function, see playground
And pass undefined make type inferring wrong. So how should I do to get it correct?
VanCoding commentedon Dec 20, 2021
I created the issue #47202 and share the view of Raphael Schweikert (@sabberworm) KageShiron and zhaoyunfeng (@zyf0330).
What I don't get in this suggestion, though, is what's the point of an optional parameter without a default vale? If it's not specified, what's the value of it then if not undefined?
MartinJohns commentedon Dec 20, 2021
The difference is at the invocation side, and it's exactly the same as your other issue. The difference is whether it should be allowed to invoke the method with an
undefinedvalue (e.g. an explicitundefinedor a union includingundefined), or if the parameter must be omitted.VanCoding commentedon Dec 20, 2021
Martin Johns (@MartinJohns) Thanks, I get it now. Then I also think that it's good the way it currently is. Sorry for interruping.. 😓
FrameMuse commentedon Sep 17, 2024
Seems reasonable, but shouldn't be more obvious? There are definitely different intentions for
(arg?: Type)and(arg = Default). Maybe it could be annotated properly? For example(arg: Defaulted<Type>) => void.