Language Service not providing autocomplete on object literal in union type

[nycdotnet]

Hi,

I'm not sure if this is possible or not, but neither VS 2015 RC with the TypeScript 1.5 beta plugin nor atom-typescript offer autocompletion in this example:

https://github.com/TypeStrong/typestrong-compiler/blob/35d8eb8662d9ad882ff29642fcb74191421d362c/typestrong-compiler.ts#L18-L19

If I remove either consoleOutput or actualVersion from the object literal passed to resolve, TypeScript will correctly complain. However, if I begin to type con or act to put those properties back, I don't get help. I'm assuming that this is because resolve() accepts ether T or Thenable<T> and perhaps the language service just gives up when it sees a union?

//cc: @basarat @mhegazy

If this is not fixable without going crazy, no big deal. The compiler is working correctly - it's just that the autocomplete experience could be better.

Thanks!

[RyanCavanaugh]

Just to explain what's happening here: Completion here works based on the properties of the contextual type. Since T|Thenable<T> has no properties (because those types have no properties in common), we don't have anything to show you.

interface A {
    x1; y1; z1;
    m; n;
}
interface B {
    x2; y2; z2;
    m; n;
}

function fn(x: A|B) { }

However, if you changed resolve to be an overloaded function, and put the object type first, you'll see completion:

function fn(x: A);
function fn(x: B);
function fn() {}

That said, a union type is almost always a better choice than an overload set for single-argument functions, so it's probably not worth the trade-off.

---

We could probably do some hackery to show the union of all the properties of a union type for purposes of computing the completion list in the language service. In services.ts#2954 (in my copy):

                    let contextualTypeMembers = typeChecker.getPropertiesOfType(contextualType);
                    if (contextualTypeMembers && contextualTypeMembers.length > 0) {
                        // Add filtered items to the completion list
                        symbols = filterContextualMembersList(contextualTypeMembers, containingObjectLiteral.properties);
                    }

Instead of calling getPropertiesOfType, we could have some other function getCompletionPropertiesOfType that special-cased union types. It might be worth prototyping to see what the experience looked like.

[nycdotnet]

Thanks for this very in-depth analysis, Ryan. Are you still on board with special-casing #1805? I know that's been somewhat dormant.

[mhegazy]

We could probably do some hackery to show the union of all the properties of a union type for purposes of computing the completion list in the language service. In services.ts#2954 (in my copy),
Instead of calling getPropertiesOfType, we could have some other function getCompletionPropertiesOfType that special-cased union types. It might be worth prototyping to see what the experience looked like.

I believe this is the correct approach. In the consumption case, you never want the union properties, you just want the properties of one of the union type constituents. showing only union properties is not helpful. since we do not know which one of the union type constituents you want, the next best thing is to give the user all options and let them decide. I have meant to add that a while back but got distracted by other issues.

[DanielRosenwasser]

Looks like it's fixed by #3615 but I'll add a test case.