Type of an Object Which Makes Function True

In TypeScript (v4.8), is there a way to enforce the following constraint: Throughout the codebase our library, our devs are introducing parameters that our end-users will specific in their own code. We would like a flexible way for developers to specify a validation function for acceptable values that the user could supply, as well as a default value in case they don't supply one. Some examples:

const a = {validator: (n:number) => n > 10, default: 15}
const b = {validator: (s:string) => string.length < 5, default: 's'}
const c = {validator: (list: Array<number>) => list.pop() === 1, default = [1, 1]}
const d = {validator: (v: boolean) => v, default = true}

I would like it to be a type error when the default makes the validator function return false.

For context: I have a similar setup currently, where the options must be explicitly listed in an Array.

type BaseConfigObject = string | boolean | number | object;

interface ConfigOption<F extends BaseConfigObject, D extends F> {
    possible_values: ReadonlyArray<F>;
    default: D;
}

export function checkedConfigOption<F extends BaseConfigObject, D extends F>(value: ConfigOption<F, D>) {
    return value;
}

Our devs then write things like:

const terminal_settings = checkedConfigOption({ possible_values: [true, false, 'auto'], default: 'auto' });
const docked_settings = checkedConfigOption({ possible_values: [true, false, 'docked'], default: false });

This leads to a type error if the default is not a member of the possible_values. This is roughly the equivalent of having a validation function of possible_values.includes(default).

My question is - is there a way to cause a type error when validator(default) is false, for any function validator and value default?

This is unfortunately impossible. In TypeScript's type system, unless a function is generic or overloaded, the return type of the function is independent of the types of any of its parameters. So inside

const a = { validator: (n: number) => n > 10, default: 15 }
const b = { validator: (s: string) => s.length < 5, default: 's' }
const c = { validator: (list: Array<number>) => list.pop() === 1, default: [1, 1] }
const d = { validator: (v: boolean) => v, default: true }

the validator properties are all functions that return boolean regardless of the input value. And although boolean is equivalent to the union type true | false, that just means that every call to the function returns "either true or false". TypeScript has no idea which input values return true and which ones return false. It might seem obvious to a human developer how to determine that, but the compiler does not analyze function bodies by simulating their behavior for different hypothetical inputs; it would be unbelievably expensive to do so, and it would be impossible to compile almost any non-trivial program. In some sense, you're expecting the compiler to actually run x.validator(x.default) at compile time, and that's just not how it works.

This is the job of runtime validation, not compile time validation, unfortunately.

I spent a little effort wondering how close you could get, though. As mentioned above, the output type is independent of the input types, unless the function is generic or overloaded.

Overloaded functions are a dead end, because currently inference with overloaded functions only looks at the last call signature (see ms/TS#43187 for more information).

Generics are mostly a dead end because abstracting over generics would require higher kinded types as described in ms/TS#1213, and TypeScript doesn't have direct support for it. You can kind of emulate support for it, so I used free-types to try, and, well... it's bad:

import { Type, A, apply } from 'free-types'
type SplitStr<T extends string, A extends string[] = []> = T extends `${infer F}${infer R}` ? SplitStr<R, [...A, F]> : A;
type BValidator<T extends string> = "5" extends keyof SplitStr<T> ? false : true;
interface $BValidator extends Type<[string]> {
type: BValidator<A<this>>
}
function bValidator<T extends string>(s: string): BValidator<T> {
return s.length < 5 as any;
}
type Validator<$T extends Type<[any]>, V extends apply<$T, [V]> extends true ? any : never> = {
validator: <U extends ($T extends Type<[infer T]> ? T : never) >(u: U) => apply<$T, [U]>,
default: V
}
const asValidator = <$T extends Type<[any]>>(
validator: <U extends ($T extends Type<[infer T]> ? T : never) >(
u: U) => apply<$T, [U]>) =>
<V extends ($T extends Type<[infer T]> ? T : never) & (
apply<$T, [V]> extends true ? any : never)>(
d: V): Validator<$T, V> => (
{ validator, default: d });
const bVal = asValidator<$BValidator>(bValidator);
const bGood = bVal("s"); // okay
// const bGood: Validator<$BValidator, "s">
bGood.validator(bGood.default); // okay
const bBad = bVal("oopsiedoodle") // error
// const bBad: Validator<$BValidator, never>

I managed to encode whether a string literal type has less than five characters, and then encode bValidator as a generic function that performs this operation at the type level as well as at runtime... but the compiler cannot verify that equivalence so I needed a type assertion.

And then I can build up a validator using asValidator(bValidator), but the compiler can't infer the higher-order generic so we need to specify it via asValidator<$BValidator>(bValidator), and then after all that, we are allowed to initialize b with a default of "s" but not with a default of "oopsiedoodle".

Blegggh. So for each validator function you'd need to painstakingly try to represent the distinction between valid and invalid inputs at the type level, and then assert that the validator function actually does that, and then describe the higher order generic type that fits it, and... yuck, no thanks.

Instead compare to the equivalent runtime version:

interface Validator<T> {
validator: (t: T) => boolean;
default: T
}
const asValidator = <T,>(validator: (t: T) => boolean, def: T) => {
if (!validator(def)) throw new Error("YOU MESSED UP!!");
return { validator, default: def };
}
const bGood = 
asValidator((s: string) => s.length < 5, "s"); // okay
const bBad = 
asValidator((s: string) => s.length < 5, "oopsiedoodle"); // YOU MESSED UP!!

This is a million times better. So, in conclusion, this is the job of runtime validation, not compile time validation, unfortunately.

Playground link to code