Optional local variables

[angryziber]

Suggestion

TypeScript already supports optional parameters and fields with a question mark.
Why not extend this feature to local variables as well, to allow them having an undefined value, e.g.

Use Cases/Examples

let optional?: number = 123
optional = undefined // allowed

in this case specifying number type is also optional:

let optional? = 123

This would complete the usage of question mark ? as nullablity/unefineability operator, similar to Kotlin.

Currently, defining an optional variable requires writing a lot of noise, e.g.

let optional: number|undefined = undefined  // too verbose

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• 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, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[MartinJohns]

But the variable in your example is not optional. It's always defined. You're confusing optional with "may be undefined".

[angryziber]

@MartinJohns I am not confusing - that's exactly what I want. No matter how you name it, it would extend the already existing syntax and make it useful for local variables as well. You already can use it for class variables aka members/properties, so why not local as well

[MartinJohns]

so why not local as well

It would complicate the implementation of #13195, if it ever is to be added. Optional properties and arguments can be missing, not only undefined, which is a relevant difference.

[RyanCavanaugh]

I don't think it makes sense to put the ? on the binding name; it's confusing. You wouldn't write let array[]; the | undefined is part of the type, not the variable. So the logical thing would be number?, which we discussed to death when adding strictNullChecks (since it might mean number | null, number | undefined, or number | null | undefined) and decided to just not do since different people would rightly declare in a split plurality that it's "obvious" which one of those it should mean and be angry when 66% of them were surprised.

[hannah23280]

I also support let name: string? to be equivalent to let name:string|undefined|null.

So as of current latest version, is this actually implemented?

[MartinJohns]

I also support let name: string? to be equivalent to let name:string|undefined|null.

Including null would just be plain confusing, because optional properties and parameters do not include null.

So as of current latest version, is this actually implemented?

No, and it (most likely) never will be implemented. The feature has been declined.

[hannah23280]

I also support let name: string? to be equivalent to let name:string|undefined|null.

Including null would just be plain confusing, because optional properties and parameters do not include null.

So as of current latest version, is this actually implemented?

No, and it (most likely) never will be implemented. The feature has been declined.

Wonder why is this a bad thing, such that it is not implemented. verbosity can be greatly reduced if implemented. I mean if using question mark to represent undefined|null can cause confusion, then other characters can be considered.

[malthe]

I think this is a great idea.

let result?: boolean;

It's obvious that result at this point is undefined. I don't think anyone in their right mind would think that it's null for example.

Now, @MartinJohns argued that supporting this would complicate #13195 – meanwhile, on Jun 1, 2021 that issue was actually resolved.

Does this mean that in principle, TypeScript could support this syntax?

I totally agree with @angryziber on this:

let result: boolean | undefined = undefined  // too verbose

And there's good code to be written that uses this syntax. In the example above, we can imagine that there is no result yet, neither success or failure.