Optional parameter with jsdoc does not be respected by salsa intellisense

[Thaina]

When I use jsdoc to create constructor the intellisense work well. Except a bug that it must obey parameter. It will not know type if the parameter is not all passed in. even it marked as optional by jsdoc

As the screenshot. air is optional by jsdoc

this work but

not

[billti]

Testing with the latest release-1.8 bits and we seem to have fixed this. Note the various different syntaxes supported for optional params below (p2 - p4 are all optional below):

Please try again with the latest bits in the release-1.8 branch, and if you are still not seeing optionality on params appear problem, comment with more details (ideally some code I can cut/paste), and I'll look into it.

Thanks!

[Thaina]

@billti I think you may misunderstand the issue a little

The problem is registering intellisense to constructor

Here is the code I use for test

/**
 * @param {string} p0
 * @param {string} [p1]
 */
function Test(p0, p1) {
    this.P0 = p0;
    this.P1 = p1;
}


var test = new Test("");

And this is result. When parameter is missing it then make an object created from that constructor to not know what it is

[Thaina]

@RyanCavanaugh @billti If you close issue then does you get notification?

[billti]

Yes, but it is the weekend (and Monday is a holiday).

[Thaina]

@billti OK then I'm apologize. Just not sure that it is or not. Because it still closed

[RyanCavanaugh]

Currently in TypeScript if you try to invoke a function (or constructor) and zero signatures match, we issue an error and return unknownType (which is effectively identical to any). This is the general pattern we use everywhere because it stops downstream errors.

However, if there are any appropriate signatures, we could give a better Salsa (and arguably a better TypeScript) experience by choosing the last signature in the set instead of unknownType. That would give you back what we generally believe to be the "most general" return type of the function, and you could start seeing downstream errors.

This is probably the right thing to do everywhere. e.g. today, even in TypeScript, if you say

function makeString(n: number) {
    return 'the number is ' + n;
}

let j = makeString(); // j: any
let k = j.subtr(4);

you get an error on the initializer for j, but nothing on the incorrect spelling of substr. That's bad for Salsa (as shown above) and bad for TypeScript because you really do have two errors (not one), and now need to go through two compilation cycles instead of one.

@ahejlsberg any thoughts on this change and/or this pattern in general?

[RyanCavanaugh]

Open question with this approach: what to do about generic signatures?

function fn<T>(x: T, y: T): T { ... }
let x = fn(3, ""); // was x: any, now x: ??