In TypeScript, what does `type Tail<S> = S extends `${infer Head}-${infer Rest}` ? Rest : never` give for `Tail<'a-b-c'>`, and what matching rule explains it?

## What the pattern is doing A template literal type in the `extends` position of a conditional type is a *matcher*. The compiler tries to align the candidate string literal type with the pattern; where the pattern has `infer X`, whatever text lines up there is captured as a new string literal type. ```ts type Tail<S> = S extends `${infer Head}-${infer Rest}` ? Rest : never; type R = Tail<"a-b-c">; // "b-c" ``` The literal segment in the pattern is the single hyphen. The compiler scans for it, and a placeholder that is followed by literal text stops at the **first** occurrence of that text. So the split happens at the leftmost hyphen: `Head` is `"a"`, `Rest` is `"b-c"`. The trailing placeholder has nothing after it to constrain it, so it takes the entire remainder — hyphens and all. If you want the *last* segment instead, you invert the shape so the greedy part is at the front: ```ts type Last<S extends string> = S extends `${string}-${infer R}` ? Last<R> : S; type L = Last<"a-b-c">; // "c" ``` Here the recursion keeps chopping from the left until no hyphen remains, and the final `S` is the last segment. The compiler gives no "match greedily" switch; you get the behaviour you want by choosing the recursion, not by a modifier. ## Adjacent placeholders split one character With no literal text between two placeholders, the first captures exactly one character: ```ts type First<S> = S extends `${infer H}${infer T}` ? H : never; type F = First<"abc">; // "a" ``` This is the primitive that character-level type-level programming is built on: capture one character, recurse on the rest, accumulate a result. It also means the empty string `""` fails to match this pattern at all, which is the natural base case for such a recursion. ## Splitting a delimited string The two rules combine into the standard split helper: ```ts type Split<S extends string, D extends string> = S extends `${infer Head}${D}${infer Rest}` ? [Head, ...Split<Rest, D>] : [S]; type Parts = Split<"a-b-c", "-">; // ["a", "b", "c"] ``` Each step peels one leading segment at the first delimiter; the false branch is the base case that wraps whatever is left. ## Route parameters, the canonical use The most-cited real application is turning a route string into the object of its parameters: ```ts type Params<S extends string> = S extends `${string}:${infer Param}/${infer Rest}` ? { [K in Param]: string } & Params<`/${Rest}`> : S extends `${string}:${infer Param}` ? { [K in Param]: string } : {}; type P = Params<"/users/:userId/posts/:postId">; // { userId: string } & { postId: string } ``` The first branch handles a parameter with more path after it; the second handles the final parameter; the third terminates on a path with no parameters left. Notice that ordering matters — the more specific pattern must be tried first, because the compiler takes the first branch whose pattern matches. ## What does not match Matching is over *types*, and only sufficiently precise ones: - `Tail<string>` is `never`. The primitive `string` is not assignable to the pattern, so the false branch wins. Any upstream widening — a `let` binding, a `+` concatenation, a value read from `JSON.parse` — collapses the result the same way. - `Tail<"abc">` is `never`, because there is no hyphen to align with the literal segment. - If the type parameter is a naked union, the conditional distributes and you get one result per member: `Tail<"a-b" | "c-d">` is `"b" | "d"`. ## Costs to respect Every recursive step is work the checker does on every compile and on every keystroke in the editor. Deep recursion over long strings hits the compiler's instantiation-depth guard and reports an excessively deep type, and even before that the editor gets sluggish. Keep the input strings short and known, prefer a single split over a general-purpose parser, and be honest that a helper which parses arbitrary strings at the type level is a maintenance cost someone will pay. And, as always, none of this survives compilation. `Params<"/users/:userId">` describes a shape; extracting the actual `userId` at runtime is still a job for `split` or a router library. The type only checks that the runtime code and the route string agree.