TypeCheck.Options (TypeCheck v0.8.0) View Source
Defines the options that TypeCheck supports on calls to use TypeCheck
.
Supported options:
:overrides
: A list of overrides for remote types. (default:[]
):default_overrides
: A boolean. If false, will not include any of the overrides of the types of Elixir's standard library (c.f.TypeCheck.DefaultOverrides.default_overrides/0
). (default:true
):enable_runtime_checks
: When true, functions that contain a@spec!
will be wrapped with a runtime check which will check the input to and result returned from the function. (Default:true
).:debug
: When true, will (at compile-time) print the generated TypeCheck-checking code. (Default:false
)
These options are usually specified as passed to use TypeCheck
,
although they may also be passed in direct calls to TypeCheck.conforms/3
(and its variants).
These options are module-specific and are read/used at compile-time.
The supported options in detail
Overrides:
The :overrides
field contains a list of remote types to be overridden by a replacement.
This is useful to be able to specify TypeCheck-types for types that you do not have control over
(because they are for instance defined in a library that is not itself using TypeCheck).
For obvious reasons, using TypeCheck directly should be preferred over overriding types.
Each of the elements in the :overrides
list should be written as {original_type, replacement_type}
.
Both of these can take the shape of either&Module.type/arity
or the longer form {Module, :type, arity}
.
An example:
use TypeCheck, overrides: [
{&Ecto.Schema.t/0, &MyProject.TypeCheckOverrides.Ecto.Schema.t/0}
]
### Enabling/Disabling runtime checks
By default, runtime checks are enabled.
In the case where the runtime checks turn out to be too slow (for instance, because of working with very large or deeply nested collections) in a particular module,
they can be turned off completely.
It is recommended to:
- Only turn them off after benchmarking has shown that this will make a significant difference.
- Only turn them off in e.g. the production environment, keeping them on in the development and test environments.
An example:
use TypeCheck, enable_runtime_checks: Mix.env() != :prod
### Debugging
Passing the option `debug: true` will at compile-time print the generated code
for all added `@spec`s, as well as `TypeCheck.conforms/3`/`TypeCheck.conforms?/3`/`TypeCheck.conforms!/3` calls.
Link to this section Summary
Types
This type is managed by TypeCheck
,
which allows checking values against the type at runtime.
An extra check is performed to ensure that the original type
and the replacement type have the same arity.
This type is managed by TypeCheck
,
which allows checking values against the type at runtime.
This type is managed by TypeCheck
,
which allows checking values against the type at runtime.
Link to this section Types
Specs
This type is managed by TypeCheck
,
which allows checking values against the type at runtime.
Full definition:
remote_type() :: mfa() | function
Specs
t() :: %TypeCheck.Options{ debug: boolean(), default_overrides: boolean(), enable_runtime_checks: boolean(), overrides: type_overrides() }
This type is managed by TypeCheck
,
which allows checking values against the type at runtime.
Full definition:
t :: %TypeCheck.Options{overrides: type_overrides(), default_overrides: boolean(), enable_runtime_checks: boolean(), debug: boolean()}
Specs
type_override() :: {remote_type(), remote_type()}
An extra check is performed to ensure that the original type
and the replacement type have the same arity.
This type is managed by TypeCheck
,
which allows checking values against the type at runtime.
Full definition:
type_override :: {original :: remote_type(), replacement :: remote_type()}
Specs
type_overrides() :: [type_override()]
This type is managed by TypeCheck
,
which allows checking values against the type at runtime.
Full definition:
type_overrides :: list(type_override())