Union types and overloads acts a bit weirdly

Acknowledgement

I have asked the question on Gitter and most of the users believe it's a bug and I have search for existing issues and didn't found any.

Issue

Let's start with the code. Playground link

declare class Foo {
	public red(): this
	public red(text: string): string
}

declare class Bar {
	public red(): this
	public red(text: string): string
}

const foo: Foo | Bar = new Foo()
const a = foo.red('text')

In the above code, I expect the variable a to be a string. However, it is string | Bar.

Now, things get even weird when I replace string with object in the return types of red method.

declare class Foo {
	public red(): this
	public red(text: string): object
}

declare class Bar {
	public red(): this
	public red(text: string): object
}

const foo: Foo | Bar = new Foo()
const a = foo.red('text')

Now suddenly, a is an object (which is correct)

More fun:

declare class Foo<T> {
    public red(): this
    public red(text: string): T
}

declare const foo: Foo<string> | Foo<number>
const a = foo.red('text'); // string | Foo<number>

It picks one overload from each member of the union, and both are incompatible with the call site.

I can confirm this is an issue on ts version 3.7.0-dev.20190823.

If Foo and Bar are given conflicting return types for the second overload:

declare class Foo {
    public red(): this
    public red(text: string): string
}

declare class Bar {
    public red(): this
    public red(text: string): number;
}

const foo: Foo | Bar = new Foo()
const a = foo.red('text'); // string?!

a is set to an invalid type string when it should be string | number.

declare class Foo {
    public red(): this
    public red(text: string): string
}

declare class Bar {
    public red(): this
    public red(text: string): number;
}

declare const foo: Foo | Bar;
//const a: string | Bar
const a = foo.red('text');

Playground

There are no generics in this example

This isn't really ideal but the overloads are in the "wrong" order and the Foo | Bar type is subject to subtype resolution, so some strangeness is bound to happen. Fixing either of those problems independently is sufficient to make things behave as expected.

Ryan Cavanaugh (@RyanCavanaugh)

Some additional fun stuff from our gitter exploration:

Take the original example:

declare class Foo {
	public red(): this
	public red(text: string): string
}

declare class Bar {
	public red(): this
	public red(text: string): string
}

declare const foo: Foo | Bar
const a = foo.red('text') // string | Bar

Rearranging the overloads in Bar fixes a
Making foo: Bar | Foo makes a: string | Foo
Adding an identical class Baz (or more) and appending the type to foo's union also appends it to the type of a

I think that's all I had. But it does trigger one peeve of mine: conceptually, I don't expect the ordering within a union or intersection to matter. It's been pointed out that overloads are represented as intersections, so ordering matters there. So I think this may be the smallest example that shows ordering sensitivity in both a union and an intersection.

😠

Also Ryan Cavanaugh (@RyanCavanaugh) can you elaborate on the 'right' order of overloads since I don't know of it being documented anywhere? I was thinking that it makes sense to order from more specific to more generic. My first thought was that the nullary version was most specific, but then it occurred to me that 1 arg is more 'specified' than no args, so maybe I had it backwards. If you could help my intuition there that would be great.

Its kind of sad that verified bugs are not getting fixed for years. :(

This is fixed. In 3.7.0-dev.20190823, the original Foo | Bar example inferred a as string | Bar, so assigning it to string produced TS2322. 5.4.0-dev.20231130 still has that result, while 5.4.0-dev.20231201 and the current native 7.1.0-dev.20260902.1 compiler infer a as string.

The later variant with string and number return types also now infers string | number.

The change was #55447 (0a877615215980a1df2c4d54e2833acdaeb0bfd6), which prefers an exact signature match before a partial match when combining union call signatures. Closing as fixed.

Navigation Menu

Repository navigation

Union types and overloads acts a bit weirdly #33101

Acknowledgement

Issue

😠

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Union types and overloads acts a bit weirdly #33101

Description

Acknowledgement

Issue

Activity

fatcerberus commented on Aug 27, 2019

webstrand commented on Aug 27, 2019

AnyhowStep commented on Aug 27, 2019

RyanCavanaugh commented on Aug 28, 2019

RyanCavanaugh commented on Aug 28, 2019

keithlayne commented on Aug 29, 2019

😠

thetutlage commented on Feb 24, 2021

RyanCavanaugh commented on Sep 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions