Consider only showing builders in object literal completions its contextual type has an index signature

[DanielRosenwasser]

Since users are no longer allowed to have excess properties in an object literal, it might be appropriate to only show a builder when the contextual type of an object literal has no index signature.

For instance:

type T = { x: string; y: number; };
function f(param: T) {
}

f({ /*$*/ }); // should only allow 'x' and 'y' and no builder.

However, this may not be sufficient; in the presence of a type assertion, one actually does want to allow a builder, since this is one of the recommended workarounds anyway:

type T = { x: string; y: number; };
function f(param: T) {
}

f(<T>{ /*$*/ }); // should only allow 'x' and 'y' and no builder.

[danquirk]

Seems like a good idea

[DanielRosenwasser]

Though I recall another edge condition is that we would need to allow a builder for the empty type as well.

[JsonFreeman]

I believe you would also want a builder when the contextual type is from a type assertion, because you are allowed to specify extra properties there as well.

You may want to look at isKnownProperty in the checker for inspiration.

[DanielRosenwasser]

@JsonFreeman sorry that's what I originally meant, I wrote "completion" instead of "a builder" in the original issue. Corrected.

[JsonFreeman]

Yes, but I meant that maybe the builder would always be shown in a type assertion, since type assertions do not view their expressions as fresh.

[DanielRosenwasser]

Right, that was what I was getting at. And actually there's another problem - consider the following:

function f(options: FooOptions): void;
function f(options: BarOptions): void;
function f(options: any) { }

Provided that FooOptions and BarOptions are non-empty and distinct, if you supply an empty object literal to f, you are potentially going to only get BarOptions (since resolution would fail on FooOptions and settle on BarOptions).

This would be bad experience. We should either supply properties from both FooOptions and BarOptions or not force completion.

[JsonFreeman]

I think that is a different issue. You'd need to detect whether multiple overloads are involved in obtaining the contextual type, and decide on a policy for this case. I think it may be acceptable to pick one and show a builder. Alternatively, you could try to collect them from all the overloads, but I think that would be complicated, and not that useful. I would also try to have completion and signature help agree on which overload the user is likely trying to call.

[RyanCavanaugh]

We'd rather error on the side of not restricting the typing here.