Hey everyone, maybe I'm overthinking this but I'm struggling with flattening the type of an array of strings to string literals. What I'm looking to do:

type Flatten<T extends string | string[]> = T extends string ? T : T[number];

function myFunc<T extends string | string[]>(input: T, item: Flatten<T>) {
  // Snipped
}

const input = ["hello", "world"]

// This should fail because "foo" is not in the array. However, it works because the type is just string instead of "hello" | "world"
myFunc(input, "foo")

// And this should work because hello is in the array, but again it will take anything that's a string.
myFunc(input, "hello")

// This does work, it only allows "hello" as the second argument
myFunc("hello", "foo") // Error! "foo" is not assignable to "hello"

When I pass in ["hello", "world"] to myFunc, I'm trying to get the input type to be constrained to "hello" | "world". I can't seem to get that to work. However, it does work if I just pass in "hello", then the input type is constrained to the string "hello".

Am I overlooking something here, or is this not possible?

Thanks to several of you here who helped me begin using recursive types, something i didn't even realize was possible.

I've been playing around with it trying to cement the concept.

The use case here was that this flatten function below wouldn't accept a number array, TS would complain about the nesting, and the recursive type solved this problem.

A flatten function that accepts nested number arrays and returns a flat number array.

However, trying to type this thing turned into lots of trial and error and the result seems hacky to me, and could be implemented much better.

The first snag of inputting the nestedArrayOrNumber<Number> type into the function was that TS complained that reduce did not exist on the type. And the hacking began when i just tried adding reduce : Function, to the interface, and the error went away! I wasn't expecting that to work honestly.

In this simple case the only extra method i had to the interface was reduce, but for all other methods available to Array, i would have to add them to the interface individually, which doesn't feel right to me.

The idea that sprang to mind, but that i was unable to implement, was trying to do a type union with the aim of : when this nestedArrayOrNumber<Number> is a number array, treat it as a Array<Number> so that we have access to all the Array methods, however, when it is a primitive number, treat it as a primitive number.

Currently the biggest confusion for me is : i was able to type "inner" on line 9, as either a number [ ], or a

nestedArrayOrNumber<Number> , and TS accepted both. But my hunch was, and it was proved with that console.log, that inner is in fact a nested number array, which made me confused as to why typing it as a number [ ] worked at all, since the whole point of the recursive type was because TS complained about passing a number [ ] as an argument to the function in the first place... any idea why the input to the function cannot be number [ ], but inside the reduce function, number [ ] will type check?

How would you recommend i improve this implementation?

apologizes for the long post, i figured it be better to be thorough in my thought process. Of course thank you for the time and generosity, i've been learning much from you.