In mapped types with key remapping, any property involving a generic type argument is dropped.

[martaver]

Bug Report

When performing key remapping in mapped types, any property involving a generic type argument is dropped from the resulting type.

🔎 Search Terms

Mapped types with generic properties
Key remapping with generic properties
Properties with generic type dropped from mapped type with 'as' key remapping

🕗 Version & Regression Information

I first noticed it in 4.9.5 and still exhibited in nightly (5.1.*). Tried every version in playground down to 4.1.*, same behavior.

This is the behavior in every version I tried, and I reviewed the FAQ for entries about Type System Behavior, Classes, Generics.

⏯ Playground Link

Playground link with relevant code

💻 Code

export type FilterNothing<T> = { [P in keyof T as T[P] extends T[P] ? P : P]: T[P] }

class Test<Z> {
    foo(args: FilterNothing<{ key: number, value: Z, bar: Date }>) {

        const { key, value, bar } = args; // value is missing
    }
}

🙁 Actual behavior

value is omitted from the resulting type, even though all properties P are emitted. Any property that has a type involving a generic type parameter always gets dropped from the key remapping.

🙂 Expected behavior

value to be on the resulting type as Z, since its key would be emitted and type looked up by T[P].

[Andarist]

I bet that your real-life example looks quite different and I'm not sure if that would be fixable.

This simple case could potentially be fixed but this conditional type stays deferred in the generic context. I'm not exactly sure why but there are some tests with // error annotations on them. This suggests that it is intended... but again, i don't know the exact reason.

The potential fix that I had in mind for this is pretty easy:

diff --git a/src/compiler/checker.ts b/src/compiler/checker.ts
index b975b98488..0a781288bd 100644
--- a/src/compiler/checker.ts
+++ b/src/compiler/checker.ts
@@ -17780,7 +17780,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
             // Instantiate the extends type including inferences for 'infer T' type parameters
             const inferredExtendsType = combinedMapper ? instantiateType(root.extendsType, combinedMapper) : extendsType;
             // We attempt to resolve the conditional type only when the check and extends types are non-generic
-            if (!checkTypeDeferred && !isDeferredType(inferredExtendsType, checkTuples)) {
+            if (checkType === inferredExtendsType || !checkTypeDeferred && !isDeferredType(inferredExtendsType, checkTuples)) {
                 // Return falseType for a definitely false extends check. We check an instantiations of the two
                 // types with type parameters mapped to the wildcard type, the most permissive instantiations
                 // possible (the wildcard type is assignable to and from all types). If those are not related,

[martaver]

Do you think the problem is in conditional types? If I test the equivalent Noop without the as key remapping, value is persisted:

type FilterNoProps<T> = { [P in keyof T]: T[P] extends T[P] ? T[P] : T[P] }

This comment might give us a hint:

// We attempt to resolve the conditional type only when the check and extends types are non-generic

So maybe it's that as in key remapping drops unresolved (deferred) types?

I'm not sure about my terminology here, so please correct me if what I'm saying makes no sense...

[Andarist]

So maybe it's that as in key remapping drops unresolved (deferred) types?

Yes, that's exactly what happens. This conditional type stays deferred and thus it fails isTypeUsableAsPropertyName check later on and ain't added as a property to the result of this whole mapped type within this generic context.

[martaver]

Is there a reason why key remapping should drop deferred types, then, or is it just incomplete?

[Andarist]

How do you access a property name that is typed using a deferred type? This conditional type decides if that property got filtered out from the type or not. If TS can't resolve it immediately then it can't assume that it's there so it becomes inaccessible.

[martaver]

That makes sense! So in other words, "How can you name a property based on a type that hasn't been resolved?"

In the cases I provide, though, the only possible outcomes are never or P (a valid property name). never should be dropped, obviously...

Maybe typescript should attempt to resolve the conditional before evaluating the property name? That way it would be able to tell whether or not it can name the property, even if the type contains generic arguments.

[Andarist]

never is dropped from the union but it has a special meaning here - it makes the mapped type filter out given property. So it's not exactly the same.

I think that it's best to visualize this outcome as equivalent to:

type Preserved = { a: 1, b: 2 }
type Filtered = { a: 1 }

type Both = Preserved | Filtered

type Ok = Both['a']
type Err = Both['b']

Conceptually a very similar thing happens, at the generic level if your property name stays deferred it can end up being both (P or never). This makes us "expand" the result into a union of all possible outcomes.

[martaver]

But in the example I provide:

export type FilterNothing<T> = { [P in keyof T as T[P] extends T[P] ? P : P]: T[P] }

There isn't anything indeterminate emitted... the conditional type's output is always P. If typescript tried to resolve this, it would know that the fact that T[P] is generic doesn't matter - and know enough to leave the property included.

Instead it doesn't even attempt it... it just sees a deferred type and lazily (in the sense of little or no effort) drops it.

[Andarist]

This is what I mentioned in one of the previous comments (here). I'm not sure why this particular type has to be deferred.

[martaver]

Ahhh... okay a little more context then...

I came across the problem trying to filter our properties that have been explicitly marked as never from a type:

type FilterNeverProps<T> = { [P in keyof T as T[P] extends never ? never : P] : T[P] }

class Test<Z> {
    foo(args: FilterNeverProps<{ key: never, value: Z, bar: Date }>) {

        const { key, value, bar } = args; // 'key' is dropped, but 'value' is too...
    }
}

In the above, I expected key to be dropped, and Z to be retained. When I sought help, I was told that since never is assignable to Z, typescript had to consider all indeterminate cases and also dropped it.

So I tried a different approach, using a branded type to mark properties I wanted dropped:

interface ignore { readonly __ignore__: "__ignore__" }

type FilterIgnoreProps<T> = { [P in keyof T as ignore extends T[P] ? never : P]: T[P] }

class Test<Z> {
    foo(args: FilterIgnoreProps<{ key: ignore, value: Z, bar: Date }>) {

        const { key, value, bar } = args; // 'key' is dropped, but again 'value' is dropped too...
    }
}

In this approach, I flipped the extends to ensure that only properties that were exactly of the ignore type are dropped. In this case, never is still assignable to Z, but if Z is never then the conditional resolves as P because ignore is NOT assignable to never:

type x = ignore extends never ? 1 : 0; // Resolves as '0'

That's what led me to try a noop conditional where both branches return P and I found that no matter what I tried, any generic type is ALWAYS dropped when used in an as key remapping.

The same is not true in a simple Identity mapped type, where Z and never are all passed through:

type Identity<T> = { [P in keyof T]: T[P] }

class Test<Z> {
    foo(args: Identity<{ key: never, value: Z, bar: Date }>) {

        const { key, value, bar } = args; // 'value' DOES exist        
    }
}

So I thought this inconsistency might be a bug!

---

Edited to emphasise that in the last case value does get passed through as Z in the mapped type.

[RyanCavanaugh]

The inconsistency is an intentional difference.

You're one of the lucky 10,000 today to learn about homomorphic mapped types - see #26063

[Andarist]

@RyanCavanaugh do you happen to know why T extends T ? 1 : 0 gets deferred?

[martaver]

I don't quite see the link between what I'm pointing out and homomorphic mapped types, @RyanCavanaugh do you think you could explain?

Is it that the as operator transforms the keys as a homomorphic mapped type? In that case, which rule is filtering out the value property? Particularly in the case of the noop where all properties will resolve as P regardless of their type?

I don't understand why as T[P] extends T[P] ? P : P should drop any properties, ever, even if their types were never.

In fact, in the noop key remapping, properties whose type are explicitly never are preserved, while Z is dropped!

e.g.

type FilterAsNoProps<T> = { [P in keyof T as T[P] extends T[P] ? P : P ]:  T[P] }

class Test<Z> {
    foo(args: FilterAsNoProps<{ key: never, value: Z, bar: Date }>) {

        const { key, value, bar } = args; // 'value' should exist                
    }
}

In the above:

1. key is never, but is preserved, because the resolved as type is always P.
2. Z COULD be never, but in that case should be treated like key, which is: preserved.
3. Z, if its NOT never, should just be considered Z, and preserves, since the as type will still always be P.

But in case 3 it's dropped...?

What am I missing here?

P.S. I've actually noticed this in many cases that the possibility of a generic type being assigned never gets in the way of doing otherwise very useful things.

[RyanCavanaugh]

I think the example given is degenerate to the point that it's not useful to discuss. If you write T[P] extends T[P] ? P : P expecting it to just exactly like P, well, then you should obviously just have written P, P is already the thing that behaves exactly like P. Discussing the behavior of that example is misleading because it has invariants that real usages with different behavior would not.

[martaver]

I mean, I was only using the example to illustrate a broader issue... which was the inability to pass generic types through any kind of key remapping.

A more concrete example would be to filter out properties that are of type never:

type FilterNeverProps<T> = { [P in keyof T as T[P] extends never ? never : P] : T[P] }

class Test<Z> {
    foo(args: FilterNeverProps<{ key: never, value: Z, bar: Date }>) {

        const { key, value, bar } = args; // 'key' is dropped, but 'value' is too...
    }
}

But then I noticed that the value property was always dropped regardless of the as clause. Hence the 'degenerate' example.

I thought the whole point of as syntax was to map property names, and (because of its special handling of never) filter them. It seems quite limiting if as always drops any properties that are of a generic type without any resolution?

[Andarist]

I think that the current logic is fine and that it's very consistent with the rest of TypeScript. As I mentioned, given that this object depends on a generic it's essentially equivalent within this method to smth like:

type Args = { bar: Date, value: Z } | { bar: Date }

TypeScript doesn't allow you to access properties that are members of some union constituents - you can only access common keys. This is exactly how it works in concrete scenarios:

type Concrete = { bar: Date, value: number } | { bar: Date }
declare const c: Concrete
// Property 'value' does not exist on type 'Concrete'.
//  Property 'value' does not exist on type '{ bar: Date; }'
c.value

It seems quite limiting if as always drops any properties that are of a generic type without any resolution?

Similar limitations are quite common in TypeScript. As long as things stay generic the reasoning capabilities are limited - often for good reasons though (and I think that this one is a good reason).

---

I think that perhaps what you would like to ask for here is the ability to narrow this implicit union using in operator:

type FilterNeverProps<T> = {
  [P in keyof T as T[P] extends never ? never : P]: T[P];
};

class Test<Z> {
  foo(args: FilterNeverProps<{ key: never; value: Z; bar: Date }>) {
    if ("value" in args) {
      args.value; // error but it wouldn't have to be
    }
  }
}

[martaver]

I think that perhaps what you would like to ask for here is the ability to narrow this implicit union using in operator:

Yeah, actually maybe this is a better way to think about it... So that if never is passed as Z, then that basically means the value property shouldn't exist, and so naturally we would have to check for it before using it at runtime.

But in practice when am I ever going to pass never to Z? In fact, I would want to prevent the case altogether and receive a type error if I did - except that we have no way to constrain a type in typescript so that it's not never.

E.g. I would be looking for something like:

type FilterNeverProps<T> = {
  [P in keyof T as T[P] extends never ? never : P]: T[P];
};

class Test<Z extends Not<never>> {
  foo(args: FilterNeverProps<{ key: never; value: Z; bar: Date }>) {
    args.value; // exists, because we know that Z is not never.
  }
}

Can't do that though because never is assignable to everything...

I really appreciate the patience and discussion, by the way, thank you for sticking with me!

[martaver]

E.g. even if I constrain Z with a concrete type like string, the never case is still considered and value is dropped:

type FilterNeverProps<T> = { [P in keyof T as T[P] extends never ? never : P]: T[P] }

class Test<Z extends string> {
    foo(args: FilterNeverProps<{ key: never, value: Z, bar: Date }>) {

        const { key, value, bar } = args; // 'value' should be (Z extends string)
    }
}

Or am I still misunderstanding something?

[Andarist]

E.g. even if I constrain Z with a concrete type like string, the never case is still considered and value is dropped:

That's just caused by what you have already mentioned - never is assignable to everything. So despite your string constraint... it can still be passed to it.

[martaver]

Yep, got that - I suppose my point is that maybe there should be a way to escape the never case, asserting not-never?

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.