branded type erroneously replaced with `never` in a conditional type

[carljohnsonnewhampshire-hue]

🔎 Search Terms

"branded types", "branded type in a conditional type", "conditional type", "type inference", "checking for branded types", "branded type conditionals", "type conditional", "conditional type", "branded type inference", "branded type detection", "branded primitive types", "conditional type returns never for branded types"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about "This conditional type returns never when it should return the true branch."

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=6.0.3#code/C4TwDgpgBARgrgcwDwBUB8UC8UVQgD2AgDsATAZygHsYArCAY2CgH4oAKXAosy4uALYwIAJ1Y4oALigAzAIYAbchACUU2YuUBuAFClGCuSOgA3I1GNgRVdfGT8hoqADIoAbyhzpARigBfNF1Layx3P09KOWIQHSA

💻 Code

type bug<T> = T extends object ? (T extends number ? T : false) : false;
declare var repro : bug<number & { a: 1 }>;
repro = {} as any

🙁 Actual behavior

any is not assignable to repro as it has never type.

🙂 Expected behavior

any should be assignable to repro because it should have number & {a:1} type.

Additional information about the issue

In TypeScript playground this bug occurs starting at TypeScript version 3.6.2 and above.

[carljohnsonnewhampshire-hue]

Current workaround I use is as follows:

type bug<__T, T = __T> = __T extends object ? (T extends number ? T : false) : false;

This worksaround the issue.

[mkantor]

any should be assignable to repro because it should have number & {a:1} type.

For what it's worth, my expectation would be for repro to be typed as false.

I'd also expect this type to be false:

type ShouldBeFalseIMO = (number & { a: 1 }) extends object ? true : false

(It's actually true)

Our different expectations probably come down to how we feel about the things discussed in #60582. In any case, I agree that never is probably not what most people expect.

---

I suspect this happens because of how conditional types narrow type parameters. The T extends object ? condition narrows T to object & T in the truthy branch, then T extends number ? narrows it further to number & object & T, but number & object is never.

Would you also expect number & object to not be never? If so that'd be a more focused way to talk about this issue.

[mkantor]

Most people would also probably not expect this natural-looking rewrite of your bug type:

type bug<T> = T extends (object & number) ? T : false;

To result in repro becoming false.

This rewrite feels like exportation, but it's clearly not equivalent to the nested conditional version.

[carljohnsonnewhampshire-hue]

I would expect number & object to be never just like string & number is never because object is a sort of one of the 'fundamental' or 'basic' types (at least intuitively because it's written in lowercase) that's not commonly used to probe for specific attributes but rather just to check whether a type is primitive or compound/object, you know?

[carljohnsonnewhampshire-hue]

Still, the branded types are very widely used all throughout all kinds of typescript projects and it's pretty natural and common and expected that number & {__brand: 'UserID'} passes both extends number and extends object checks, so although I do get where this bug is stemming from now that you've explained that it's related to type narrowing in type conditionals, I do feel like adjusting the narrowing logic somehow to take branded types into account is the right thing to do here

[mkantor]

it's pretty natural and common and expected that number & {__brand: 'UserID'} passes […] extends object checks

I've mentioned that this isn't natural/expected from my point of view, though I can't say whether my perspective or yours is more common.

Here's another scenario:

type ThisIsFalse = string extends object ? true : false
type ThisIsTrue = (string & { length: number }) extends object ? true : false
type ThisIsNumber = string['length']

It's easy to think of string & { length: number } as being "just string" (after all, strings already have a length property of type number). Yet as we can see, that isn't the case.

I understand why the type system behaves this way (types aren't really sets of values, despite that being a common way to characterize them), but I still find behavior like this to be counter-intuitive.

[RyanCavanaugh]

passes both extends number and extends object checks

This is a runtime impossibility; nothing is both. Can you describe why this is expected? Just because it's never?

[jcalz]

I expect that {} extends object, given #56205 and #60582. I don't really like it, but I do expect it at this point. So I also expect the unfortunate situation where (number & {}) is assignable to both number and object despite number & {} not being never.

I don't really see this as a bug anywhere, just the messy result of blood sport between two type system edge cases.

[carljohnsonnewhampshire-hue]

It's easy to think of string & { length: number } as being "just string"

It's easy to think that from a human reasoning perspective, in my opinion as soon as compiler encounters something 'cursed' like this where primitive type is intersected with a record type it should not try to be smart about it and figure out whether it's still actually just a string, the whole thing should either be just straight-up forbidden and result in never type, or be left alone as the user clearly wants do something weird so just let them.

This is a runtime impossibility; nothing is both.

I agree with you. Now that I think of it it's fine that in this particular use case with nested conditionals I posted the result is never, it makes sense from type narrowing perspective.
I have only one humble request, please don't change the fact that string & {__mystring:true} passes the extends object check, I have multiple projects relying on it, that's my only request, just let it be, please.

I don't really see this as a bug anywhere, just the messy result of blood sport between two type system edge cases.

I fully agree with you.

Thanks to all for participating in the discussion and providing a broader perspective.

[carljohnsonnewhampshire-hue]

Oh, sorry,

Can you describe why this is expected?

As I was saying I think when the compiler sees such weird-but-allowed-because-common-idiom thing, as it is already the case that this use-case is recognized and common and established and supported and people depend on it (the existence and use of branded primitive types, I mean), leave it be and just satisfy the expectations around such type in the type system. This seemingly nonsensical thing already exists, it should have been just rejected/forbidden but as it is allowed and won't be banned, just go with the flow you know? It says that it's a string and some object at the same time, it does not make any sense and is not possible at runtime but it is supported by the type system and the fact that user made such a type means they intend to interact with it somehow in the type system space, so why not play along with the constraints that this nonsensical yet allowed valid first-citizen type declares it satisfies? You know what I mean? Anyway, this is just my perspective, thanks for reading.

[RyanCavanaugh]

As mentioned earlier, the crux of this is really the "narrowing" of type parameters in the true branch of conditional types. This is also referred to as "substitution types" in case you want to explore that rabbit hole.

A good alternative approach would be:

type IsBrandedNumber<T> = [T extends number ? true : false, T extends object ? true : false] extends [true, true] ? 'ya' : 'no';
type X = IsBrandedNumber<number & { a: 1 }>;
//   ^?
type Y = IsBrandedNumber<number>;
//   ^?
type Z = IsBrandedNumber<{ a: 1 }>;
//   ^?

The problem here is that TypeScript doesn't have branded types. The thing that is happening are workarounds, and if workarounds didn't have trade-offs, they wouldn't be called workarounds. This is exemplified here, where we say (for the sake of some problems) that { x: number } extends object because 99% of the time it does, but where we don't say that number & { x: number } is immediately never even though that's the straightforward implication of what those two things mean.

It's just literally impossible to both "go with the flow" and allow these lies without incurring the sort of discontinuities in logic that you're observing here. It's like trying to say 2 + 2 = 5 and then being surprised that 5 - 2 is 3 -- when something illogical is allowed in the first place, something has to give somewhere.

[carljohnsonnewhampshire-hue]

You're right, I agree with you, it makes sense. Thanks for an in-depth explanation. Still, just don't ever break string & {x:1} extends object, okay? My well-being depends on it as I'm involved in multiple ~200k loc closed source typescript projects where this (arti)fact is largery relied upon, okay? Thank you

[mkantor]

I expect that {} extends object, given #56205 and #60582. I don't really like it, but I do expect it at this point.

Framed that way, me too. I should've said "expect¹".

Footnotes

1. While wearing my platonic-ideal-of-what-the-type-system-wants-to-be-tinted glasses (which look very similar to my newcomer-trying-to-learn-TypeScript-tinted glasses). ↩

[carljohnsonnewhampshire-hue]

Alright thanks everyone, not a bug