Documentation

Function type signatures

A function type signature describes a function’s input parameters and types, and the function’s output type. Use type signatures to identify data types expected by function parameters and to understand a function’s expected output.

Function type signature structure

(parameter: type) => output-type

Parameter notation

Parameter notation indicates specific behaviors of function parameters.

?  // Optional parameter
<- // Pipe receive – indicates the parameter that, by default, represents
   // the piped-forward value

Type variables

Flux type signatures use type variables to represent unique types in the signature. A type variable is polymorphic, meaning it can be one of many types, and may be constrained by type constraints.

Type variables use the following identifier patterns:

A
B
C
t11
// etc.

Type notation

Stream types

Type signatures identify stream types (streams of tables) using the stream[A] syntax where A is a unique type variable. Stream types may included specific column names and column types.

// Stream of tables
stream[A]

// Stream of tables with specific columns, but inferred column types.
stream[{col1: A, col2: B}]

// Stream of tables additional or required "count" column with an
// explicit integer type.
stream[{A with count: int}]

Basic types

Type signatures identify basic types with the following type identifiers:

bool     // boolean type
bytes    // bytes type
duration // duration type
float    // float type
int      // integer type
regexp   // regular expression type
string   // string type
time     // time type
uint     // unsigned integer type

Composite types

Type signatures identify Flux composite types with the following syntaxes:

[A]             // array type
[B: A]          // dictionary type
(param: A) => B // function type
{_value: int}   // record type

Type constraints

Some function parameters are “polymorphic” and can support multiple data types. Polymorphic parameters are bound by type constraints, which define what types can be used. Type signatures indicate type constraints for specific values using the where A: Constraint syntax.

For example, the following type signature describes a function that takes a single parameter, v and returns and integer. v can be any type that satisfies the Timeable constraint (duration or time).

(v: A) => int where A: Timeable

For more information about the different type constraints and the types each supports, see Type constraints.

Example function type signatures


Function without parameters

The following type signature describes a function that:

  • Has no parameters
  • Returns a time value
() => time

Function with parameters

The following type signature describes a function that:

  • Has two parameters of type A:
    • multiplier (Optional)
    • v (Required)
  • Returns a value the same type as the two input parameters
(?multiplier: A, v: A) => A

Pass-through transformation

The following type signature describes a transformation that:

  • Takes a stream of tables of type A as piped-forward input
  • Returns the input stream of tables with an unmodified type
(<-tables: stream[A]) => stream[A]

Basic transformation

The following type signature describes a transformation that:

  • Takes a stream of tables of type A as piped-forward input
  • Has an fn parameter with a function type
    • fn uses type A as input and returns type B
  • Returns a new, modified stream of tables of type B
(<-tables: stream[A], fn: (r: A) => B,) => stream[B]

Transformation that adds a column with an explicit type

The following type signature describes a transformation that:

  • Takes a stream of tables of type A as piped-forward input
  • Has a required tag parameter of type B
    • The B type is constrained by the Stringable constraint
  • Returns a new, modified stream of tables of type A that includes a tag column with string values
(<-tables: stream[A], tag: B) => stream[{A with tag: string}] where B: Stringable

Was this page helpful?

Thank you for your feedback!


The future of Flux

Flux is going into maintenance mode. You can continue using it as you currently are without any changes to your code.

Flux is going into maintenance mode and will not be supported in InfluxDB 3.0. This was a decision based on the broad demand for SQL and the continued growth and adoption of InfluxQL. We are continuing to support Flux for users in 1.x and 2.x so you can continue using it with no changes to your code. If you are interested in transitioning to InfluxDB 3.0 and want to future-proof your code, we suggest using InfluxQL.

For information about the future of Flux, see the following: