Includes with Aaron Harper - TypeScript Type Challenges #898 [EASY]

Includes requires us to start thinking abstractly about how to leverage recursion in writing comprehensive TypeScript types. Although it's difficult at first, don't worry. We're going to be doing quite a lot of recursion in future challenges.

00:00 description of the challenge
00:41 attempt at a solution
04:12 all tests pass
05:44 alternatives
08:16 closing thoughts

[MichiganTypeScript]

Aaron Harper is a software engineer at Inngest, building an SDK-driven platform that simplifies event-driven architecture. TypeScript and Go are his languages of choice, but he's cool with anything that lets him stay far away from object-oriented programming. He loves programming, gardening, and spending time outside with his growing family.

[FunctionGermany]

i'm pretty sure the ternary-looking-like nature of conditional types is that they are always type-expressions.
in regular languages (like JS but also others) when you use control flow keywords instead of ternaries, there's a possibility that you don't return a value from a function or that you just something completely differently. with ternaries, there's absolutely no ambiguity that you're only dealing with a (type-) expression, it can always be collapsed to a single type. no side effects or other statements.
in some programming languages, using ternaries instead of if-else allows the compiler or JIT to make additional performance optimisations because of the restricted and therefore more predictable nature of ternaries.

so TL;DR the reason could simply be that other structures, like a typescript if-else, could be significantly slower under certain conditions (no pun intended).

PS: one of the programs i use for DJing is called Virtual DJ and has it's own scripting language called VDJscript for customising the behaviour of DJ hardware controls. it also doesn't have if/else etc. but it does have a ternary syntax. the reason here is also likely performance because you don't want to give people the option to write potentially very slow scripts that might make the software lag when performing, which would be terrible.

[afonsocarvalho]

why do you have to split the array in Head and Tails and not use T[number]?

[QwDragon]

I think, using Equals is cheating.
When I was trying to solve it, I make it for all tests excetp 2 with readonly.
I thought there should be a simplier way, as checking for readonly is the first in extreme section.

By the way, I have an alternate solution with Equals that inverts branches:
type Includes<T extends readonly any[], U> = true extends { [key in keyof T]: Equal<T[key], U> }[keyof T] ? true : false

But actually I started from writing recursive version.

[balajibalamurugan]

can you please remove the [easy] label, tbh its not so hard to wrap my mind 😅