Back out from reducing template literal types with no extra texts too eagerly #58703
Conversation
typescript-bot
added
the
For Milestone Bug
| @@ -26217,6 +26218,10 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
| } | |||
|
|
|||
| function inferToTemplateLiteralType(source: Type, target: TemplateLiteralType) { | |||
| if (isTemplateLiteralTypeWithSinglePlaceholderAndNoExtraTexts(source) && isTemplateLiteralTypeWithSinglePlaceholderAndNoExtraTexts(target)) { | |||
There was a problem hiding this comment.
I'm still considering if this shouldn't have some extra rules on top of this to be completely safe
There was a problem hiding this comment.
I'm not understanding why this needs to be here. After reverting #55371 the following works just fine:
declare function bar<T extends string>(x: `${T}`): T;
function baz<U extends string>(x: `${U}`) {
return bar(x); // Infers U
}There was a problem hiding this comment.
Hmm, I confused myself which one of those errored after reverting #55371:
interface TypeMap {
a: 'A'
b: 'B'
}
declare const f: <T extends 'a' | 'b'>(x: `${T}`) => TypeMap[T];
type F1 = <T extends 'a' | 'b'>(x: `${T}`) => TypeMap[T];
const f1: F1 = f; // Ok
type F2 = <T extends 'a' | 'b'>(x: `${T}`) => TypeMap[`${T}`];
const f2: F2 = f; // Error, T is not assignable to `${T}`Then I just knew where I could try to improve inference for this as I knew that in here `${T}` was being inferred for T based on `${T}` source and `${T}` target as that originally created an issue further down the road.
i agree, this PR is completely redundant 🤦♂️ this is what I get for jumping too quickly between work, this, and the kids
There was a problem hiding this comment.
Oh, I know the feeling. Your efforts are always appreciated!
| type F1 = <T1 extends "a" | "b">(x: `${T1}`) => TypeMap[T1]; | ||
| const f1: F1 = f; | ||
| type F2 = <T2 extends 'a' | 'b'>(x: `${T2}`) => TypeMap[`${T2}`] | ||
| const f2: F2 = f |
There was a problem hiding this comment.
before #55371 this was OK but the assignment above was not. The one above being an error was really spooky as both functions (source and the target there) were syntactically identical.
This line here doesn't come from the user report per se but rather it was created in the process of analyzing the error reported previously for that first assignment (since the error mentioned template literal type at that changed position in the indexed access).
I think it still might be possible to fix this case here, string like index types in the indexed accesses are stringified:
enum E { a = "a" }
type Foo = { [E.a]: 1 } // type Foo = { a: 1; }So it feels like this fact could be leveraged to simplify such indexed access types like here
| && !types[0].symbol?.declarations?.some(d => d.parent.kind === SyntaxKind.InferType) | ||
| && isTypeAssignableTo(types[0], stringType) | ||
| ) { | ||
| if (texts.length === 2 && texts[0] === "" && texts[1] === "" && (types[0].flags & TypeFlags.StringMapping)) { |
There was a problem hiding this comment.
What's the reasoning for keeping the reduction around for string mapping types? Does it fix a known issue?
There was a problem hiding this comment.
no, it just keeps the behavior from #55371 as this one seems like a safe reduction and i thought that it might be worth avoiding a new type identity in a case like this
|
@typescript-bot pack this |
|
Hey @gabritto, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running There is also a playground for this build and an npm module you can use via |
fixes #58687