`Static` types cannot be used to enforce types from a generic parameter

[ehaynes99]

When creating a function with a generic parameter of type TSchema, that parameter cannot be used to enforce types with Static, StaticEncode, or StaticDecode. It appears that the effective type in this scenario is just any. All of the below compile under strict mode:

import { type Static, type StaticDecode, type StaticEncode, type TSchema, Type } from '@sinclair/typebox'

const getStatic = <T extends TSchema>(schema: T): Static<T> => {
  return 'anything'
}

const getStaticEncode = <T extends TSchema>(schema: T): StaticEncode<T> => {
  return true
}

const getStaticDecode = <T extends TSchema>(schema: T): StaticDecode<T> => {
  return undefined
}

const BoolString = Type.Transform(Type.Boolean())
  .Decode(String)
  .Encode((str) => str === 'true')

const Model = Type.Object({
  first: Type.String(),
  second: BoolString,
})

// inferred type
// const static: {
//   first: string
//   second: boolean
// }
const staticValue = getStatic(Model)

// inferred type
// const staticEncode: {
//   first: string
//   second: boolean
// }
const staticEncodeValue = getStaticEncode(Model)

// inferred type
// const staticDecode: {
//   first: string
//   second: string
// }
const staticDecodeValue = getStaticDecode(Model)

Playground Link

[sinclairzx81]

@ehaynes99 Hi! This is an interesting one.

When creating a function with a generic parameter of type TSchema, that parameter cannot be used to enforce types with Static, StaticEncode, or StaticDecode. It appears that the effective type in this scenario is just any. All of the below compile under strict mode:

So passing a TSchema to a Static inference type will infer as unknown.

type T = Static<TSchema>        // type T = unknown
type D = StaticDecode<TSchema>  // type D = unknown
type E = StaticEncode<TSchema>  // type E = unknown

This extends to functions when Static is used as a return type.

// all these are fine from the compilers standpoint
const getStatic = <T extends TSchema>(schema: T): /* Static<T> */ unknown => 'anything'
const getStaticEncode = <T extends TSchema>(schema: T): /* StaticEncode<T> */ unknown  => true
const getStaticDecode = <T extends TSchema>(schema: T): /* StaticDecode<T> */ unknown => undefined

However, if you make the return type part of the generic signature (introduced as R), you can get TypeScript to raise an error.

TypeScript Link Here

// error type: 'R' could be instantiated with an arbitrary type which could be unrelated to '...'

const getStatic = <T extends TSchema, R = Static<T>>(schema: T): R => {
  return 'anything' // Type 'string' is not assignable to type 'R'
}

const getStaticEncode = <T extends TSchema, R = StaticEncode<T>>(schema: T): R => {
  return true // Type 'boolean' is not assignable to type 'R'
}

const getStaticDecode = <T extends TSchema, R = StaticDecode<T>>(schema: T): R => {
  return undefined // // Type 'undefined' is not assignable to type 'R'
}

I believe the above works as it makes TypeScript aware that the return type R is directly dependent upon the parameter type T and where both T and R cannot be known in advance. TypeBox uses this technique internally as it helps to ensure type safety and also because it can lead to more efficient inference (as TypeScript tends to evaluate return types differently in support of control flow analysis ... this technique by-passes it)

Hope this helps! S

[ehaynes99]

Huh, yeah, that's interesting. That does indeed solve the problem, but this is one of those covariance/contravariance issues that really feel broken. TS allows narrowing in subtypes, but then doesn't consider the possibility of that narrowing when enforcing types. I really didn't expect it here, though... Any subtype of TSchema will have a static property that is assignable to unknown, but unknown is not necessarily assignable to the type of the static property of arbitrary subtypes of TSchema.

It's similar to:

export interface Example1 {
  example(value: string | number): string
}

const example1: Example1 = {
  example: (value: string) => value.toUpperCase(),
}

// runtime error!
example1.example(111)

export interface Example2 {
  example(value: string): string
}

// fine
const example2: Example2 = {
  example: (value: string | number) => String(value),
}

// surprising lack of consistency
export interface Example3 {
  example: (value: string | number) => string
}

const example3: Example3 = {
  // compile error:
  // typescript: Type '(value: string) => string' is not
  // assignable to type '(value: string | number) => string'.
  example: (value: string) => value.toUpperCase(),
}

[ehaynes99]

Actually, on further inspection, that doesn't work either. Supplying the second generic parameter solves the problem above and prevents returning an arbitrary, unrelated value, but it also creates the opposite problem in that a verified Static<T> isn't necessarily the same type as R. For example:

export const check = <T extends TSchema, R = StaticEncode<T>>(
  schema: T, //
  value: unknown,
): R => {
  if (!Value.Check(schema, value)) {
    throw new TypeError('Invalid value')
  }

  // typescript: Type 'Static<T>' is not assignable to type 'R'.
  //   'Static<T>' is assignable to the constraint of type 'R', but 'R'
  //   could be instantiated with a different subtype of constraint 'unknown'. [2322]
  return value
}

That error is correct (and honestly what I expected in the original scenario). Since the return type is now specified by the caller, R could be any arbitrary type:

const value: number = check<TString, number>(Type.String(), 'hello')

Even with an added constraint of R extends StaticEncode<T> = StaticEncode<T> it's still not safe. E.g.

const Model = Type.Object({
  name: Type.String(),
  age: Type.Optional(Type.Number()),
})
type Model = Static<typeof Model>
type Model2 = Model & {
  email: string
}

// value is only guaranteed to be a `Model`, not a `Model2`, but the generic parameter
const value: Model2 = check<typeof Model, Model2>(Model, {
  name: 'Joe Schmoe',
  age: 42,
})

An in fact, the compiler will infer the type from the assignment even if you omit the generic parameters:

I'm not sure there's really any solution here. It's too fundamental to how the derived types work. The problem will exist in one direction or the other. I think I'm better off with the original case. At least there, I can test my generic functions' output, and the callers will have properly enforced types.