Is there any (current or planned) support for function types?

[gwhitney]

I was thinking of something along the lines of

export const transmogrifier = type({
    name: "string",
    behavior: "(a: number, b: number) => number"
})

I didn't see anything about specifying that a property should have as its value a function, but perhaps I've just missed it?

[ssalbdivad]

There's no ability to parse function signature types because function signatures can never be validated at runtime.

What you like to do with this type?

[matthew-dean]

Whoa! Yes! Especially if types were inferred properly in the function. Although.... is validating optional? Or the actions being taken when validating optional?

[ssalbdivad]

Yes the types can be inferred precisely. There will be a version of the API with parameter/return validation and a version (primarily for JS) without it just to get access to the types

[matthew-dean]

Oh wow, when?

[matthew-dean]

In the meantime, I was able to do this:

import { validate } from './_util'

import { type } from 'arktype'
const argsType = type({
  0: ['instanceof', Dimension]
})

const validateFloor = (...args: any[]) => validate(floor, ['value'], argsType(args))

function floor(value: Dimension) {
  validateFloor(arguments)
  return new Dimension([Math.floor(value.number), value.unit])
}

[matthew-dean]

However, when I tried the following, I got an error. The scope feature and its documentation is quite opaque at the moment 🤔

import { type, scope } from 'arktype'
export const types = scope({
  dimension: ['instanceof', Dimension],
  dimNumber: 'dimension|number'
}).compile()
const argsType = type({
  0: types.dimNumber
})

const validateFloor = (...args: any[]) => validate(floor, ['value'], argsType(args))

function floor(value: Dimension) {
  validateFloor(arguments)
  return new Dimension([Math.floor(value.number), value.unit])
}

[thetayloredman]

The best thing you could do is type as Function. Like David said, there's no way for AT to check at runtime what the type of arguments a function would accept is. If you want validated I/O for a function, you could write a simple wrapper for it?

[gwhitney]

More background: I am passing collections of functions into a sort of dispatcher. At runtime, the dispatcher needs to know the parameter types of the functions because it uses that information to select which function to call. But I want TypeScript to typecheck the functions that are being passed into the dispatcher at compile time. So I need the function types as static types at compile time, and a runtime-value description of them at runtime. I've looked at type reflection libraries like typescript-rtti and so far they are not up to the challenge. So I thought of turning this around and specifying the type with a runtime-value description from which TypeScript can infer the type at compile time. Seeing ArkType billed as something that can "infer TypeScript definitions 1:1" therefore was naturally very attractive. But for this use case, it would need a notation for specific function types.

To make this more concrete, let's say I am trying to describe a bundle of two functions like

type Bundle = { 
  stringHandler: (a: string) => number,
  numHandler: (n: number) => number
}

The Dispatcher will be generic on the type of the bundle of functions, something like

const myDispatcher = Dispatcher<Bundle>({
  stringHandler: (s) => s.length,
  numHandler: (k) => 2*k
})

but I do want the compiler to check at compile time that the bundle of functions have the correct types, as the above code will. But now to use the bundle and call the correct function in a given circumstance when it runs, the code in Dispatcher needs to have runtime information about what the parameter types of each of the members of the bundle were. So there really needs to be a second argument like Dispatcher<Bundle>(theBundle, bundleDescription) that provides that information. So putting it all together, I was thinking of something like

import { type } from "arktype"

const bundleDescription = {
  stringHandler: '(a: string) => number',
  numHandler: '(n: number) => number',
}

const bundler = type(bundleDescription)
type Bundle = ReturnType<typeof bundler>['data'] // or whatever expression...
     // statically infers the type described by bundleDescription

const myDispatcher = Dispatcher<Bundle>({
  stringHandler: (s) => s.length,
  numHandler: (i) => 2*i
}, bundleDescription)

that way the functions used to create the Dispatcher are typechecked at compile time, and the Dispatcher has a description it can compute with to use those functions at runtime. In particular, the Dispatcher will be able to determine which function in the bundle handles strings, for example, by consulting the bundleDescription. There's very little redundancy, and I get type safety at compile time and the information I need at runtime.

Is this making more sense? I believe that if arktype could statically infer function types for object properties along with all of the other types it describes, it would cover exactly this need. In other words, it seems to me that arktype could also help with compile-time typechecking of code in addition to run-time validation of data. Thanks for your thoughts.

[thetayloredman]

ArkType validators take type unknown, it would not help you validate at compile-time (if I am understanding your problem)

[gwhitney]

Confused -- I got the impression that arktype inferred the described type statically at compile time. That's all I need, so I can extract the type described by the json, and then use that type as the type parameter to my generic function so it will check the types of the supplied bundle of functions at compile time. Am I mistaken that arktype generates a compile-time entity with the exact TypeScript type described by the literal argument to type() ? Isn't such a type part of the inferred type of the call to type()? Or am I mistaken?

[thetayloredman]

That inferred type is what is returned from the validator. AT will not check that what you pass to the validator is of that type at compile time, it accepts unknown.

[ssalbdivad]

So there's a few ideas that come to mind. One of them would be a dedicated syntax like this, which I'm planning to add after beta release as a way to create validated functions and/or typed JS:

TypesInJs.mp4

So that would be a possibility in terms of a function definition format that could have type metadata attached.

Another option that comes to mind, depending on how much control you have over these structures, is to do something more like pattern matching, where the keys could be types themselves, and then depending on which branch the data satisfies you'd execute that handler.

In terms of features that are currently available, I think the most straightforward would be to just approximate pattern matching- define the input types for the various functions, then check if each one .allows the data to decide which dispatch to run.

[gwhitney]

yes, that fn() (presuming it properly typed when used in TypeScript) would definitely be helpful, especially if it in turn had a notation for properties of its argument type being of specific function types themselves.

And in terms of pattern matching, well, yes, we are basically working on a sort of pattern matcher -- that's what the thing I called the Dispatcher is. It's just a little generalized because the different patterns can be defined in many different compilation units (to allow the code to be decoupled/factored in a way where the collection of modules you import determines the collection of patterns that can be handled), rather than needing to all be collected in one place for a single match() call. But once you've done all the imports and build the Dispatcher, you get a single function that can handle any of the patterns that were found in any of the imports. SO we need the building block of being able to specify the different handlers, with the complication that handlers are allowed to depend on each other, so we also need to be able to record the DAG of dependencies and inject them when the final Dispatcher is built. (Ultimately, this is for a computer algebra system, which is to be extendible with additional abstract mathematical structures like matrices or values with units or exact rational numbers just by importing an additional module, without having to redefine every operation for the new structures, just the basic ones that the more intricate ones are built from.)

[gwhitney]

Philosophically, if arktype is going for 1:1 Typescript type correspondence, why not add specific function types even though the ability to validate them from data of type unknown is (currently anyway) limited?

[ssalbdivad]

Sounds like a really cool project! Would love to see more as its developed- I've always loved math and I don't get to work directly with it often enough :-)

It seems like the ability to define function types would be covered by the fn API I mentioned. It could have attached metadata for introspecting types, and could optionally validate inputs then delegate to your implementation.

[mdmundo]

amazing! any update on this?

[ssalbdivad]

@mdmundo I just merged a prerelease of 2.0.

The function API is a pretty trivial wrapper so the main reasons I'd avoid including it are:

• To avoid overwhelming people early on
• To avoid committing to an API I'm not sure of

I do think this would be very useful though so I definitely plan to add it in the near future if not on release.