Implement new overload compatibility checking

[DanielRosenwasser]

Addresses #943 and #4180.

This PR loosens the compatibility rules between an implementation and an overload. We now check for both

• whether the implementation is assignable to the overload, while disregarding return types
• whether the implementation return type is assignable to or from the overload return type

This means that something like

function getAnimal(x: number): Dog;
function getAnimal(x: string): Cat;
function getAnimal(x: number | string): Cat | Dog {
    // ...
}

will finally work, as will

function getAnimal(x: number): Dog;
function getAnimal(x: string): Cat;
function getAnimal(x: number | string): Animal {
    // ...
}

[JsonFreeman]

In response to @weswigham's point #943 (comment), I believe the special casing of signature return types wouldn't come into play here. The return types are being compared solely as types, and not signature return types. So I think boolean would be assignable to a type predicate in this context, which is indeed desirable.

[DanielRosenwasser]

Exactly, and you can see that in stringLiteralTypesAsTags01.ts. I'll have to add more test cases though.

[JsonFreeman]

My ultimate point is that concern number 2 in #943 (comment) is not an issue, since boolean would work in the /*????*/ slot.

[ahejlsberg]

We're computing and caching an awful lot of types here. They'll sit in the cache of their associated signature forever and also gum up the assignable relation cache. I think we need a function similar to compareSignatures that checks for assignability instead of identity. The function could have an ignoreReturnTypes flag and then you wouldn't need to create all of these new signatures and types.

[JsonFreeman]

Agreed.

One other possibility is to just call isSignatureAssignableTo in both directions. For the return types, doing this would yield the bivariance you are seeking. Parameter types are bivariant anyway, so each corresponding pair would just get checked in both directions twice. The only real difference is that you'd be extra permissive with the arity checks on the signatures. Namely, an overload would be allowed to be shorter (fewer parameters) than the implementation signature. You could add the necessary arity checks after the comparison to make sure the arities are only related in the direction you want. It's kind of nifty, though perhaps a bit more roundabout than the compareSignatures style approach.

[DanielRosenwasser]

isSignatureAssignableTo was already doing the work I was trying to avoid, so I might as well just avoid the caching.

[DanielRosenwasser]

I've pushed out a change that does as @ahejlsberg's requested. There's no caching and no new type creation.

[JsonFreeman]

Yes, this is concerning. There is a lot of duplicated functionality here.

[DanielRosenwasser]

I have a separate branch for that work right now, but I'd like to get it in as part of a separate PR.

[sandersn]

It looks like it's mostly down to isRelatedTo vs isSignatureAssignableTo and Ternary vs boolean. Am I missing something?

[sandersn]

I think you can use fewer words here: Just say "Preserve behaviour forbidding boolean functions from being assignable to type guards."

[sandersn]

Might as well change the original in signatureRelatedTo also

[sandersn]

Looks good enough to merge if the de-dupe cleanup is coming soon. The semantics a bit loose for my liking but they are more consistent with existing Typescript.

[DanielRosenwasser]

If you'd like to discuss the semantics tomorrow, I'm open to it. 1.8 isn't set in stone just yet.