Intellisense: optional parameters are too verbose (bar? number | undefined)

[sn0wcat]

Search Terms

optional parameters intellisense

Suggestion

The intellisense for optional parameters is too verbose:

an optional function parameter defined e.g. like this

function foo (bar?: number) {
}

gets resolved in the intellisense as

function foo(bar?: number | undefined): void

The optional nature of the bar parameter is indicated two times, once with number | undefined type and once with the question mark sign bar?:

Proposal:

Just use question mark in intellisense signatures

function foo(bar?: number): void

Use Cases

The | undefined bloats the length of the function signatures generated by the intellisense. This makes the signatures too long leading to loss of important information in the intellisense in longer methods (e.g. the return types are shortened...)

Examples

Here is an example:

class IotFileClient {
public async GetFiles(
        entityid: string,
        params?: { 
            offset?: number; 
            limit?: number; 
            count?: boolean; 
            order?: string; 
            filter?: string; 
            }
    ): Promise<IotFileModels.IFile> {
         return {name: "test"};
    }
}

This produces the intellisense output like this:

(method) IotFileClient.GetFiles(entityid: string, params?: {
    offset?: number | undefined;
    limit?: number | undefined;
    count?: boolean | undefined;
    order?: string | undefined;
    filter?: string | undefined;
} | undefined): Promise<...>

Using only ?: would reduce the verbosity and leave much more room for the important information e.g. for the return values:

(method) IotFileClient.GetFiles(entityid: string, params?: {
    offset?: number;
    limit?: number;
    count?: boolean;
    order?: string;
    filter?: string;
}): Promise<IotFileModels.IFile>

http://www.typescriptlang.org/play/#code/KYDwDg9gTgLgBAOwIYFtgGcxIMbDgSQhgDEBLAG2AFkIATYc9OAbwCg4O5RJY5SEYwKADMcefGUot2nWcjQAuOOhhR+AcwDcMjgF9W+1tnJJ0TQiQrAAwuVLAB0sAFcARnexxTATwSeA4sCWlOgAFDqyXAKkMN6ktEoqagjqADQRslhQqOgA-ErMcBmRHBDCwuhB+YjOKK5CmkUlJXYoMdUItfVQjcUl2BDOAtWuEBCUSAi9zZHQ9FDVSRrTM5zCFIILCksp2quc+rIAlEoAClAQbZUAPBaS1HQM6AB0ElYAfNKrUEHOUAgseTAJQAIkEKhBuj2BwMrFYwiG2BgpAgAOEYzgoVcSC2NTqQiOXyKuiAA

Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

[poseidonCore]

Just to clarify the context, this behaviour occurs when strictNullChecks is on, but not usually when it is off.

[sandersn]

Seems reasonable to me. We expect people to write parameters this way, and only print them the other way by default, and because being explicit seems like a good teaching tool for how to use strictNullChecks.

[coding4funrocks]

This would be great. I prefer the shorter method signature in the IntelliSense as well.