Version 0.11.0 has been released!

Wooh, this is a big release!

Most important features:

• We now support all of Elixir’s builtin basic types!
• We now support all of the remote types of the Elixir standard library!
• Support for most of the map-type syntactic sugars.
• An optional Credo check to enforce that all your functions have a spec.

Full changelog

Additions

• Support for fancier map syntaxes:
  • %{required(key_type) => value_type} Maps with a single kind of required key-value type.
  • %{optional(key_type) => value_type} Maps with a single kind of optional key-value type.
  • %{:some => a(), :fixed => b(), :keys => c(), optional(atom()) => any()} Maps with any number of fixed keys and a single optional key-value type.
  • TypeCheck now supports nearly all kinds of map types that see use. Archaic combinations of optional and required are not supported, but also not very useful types in practice.
  • Because of this, the inspection of the builtin type map(key, value) has been changed to look the same as an optional map. This is a minor backwards-incompatible change.
• Desugaring %{} has changed from ‘any map’ to ‘the empty map’ in line with Elixir’s Typespecs. This is a minor backwards-incompatible change.
• Support for the builtin types port(), reference() and (based on these) identifier().
• Support for the builtin type struct().
• Support for the builtin type timeout().
• Support for the builtin type nonempty_charlist() and maybe_improper_list and (based on these) iolist() and iodata().
• Adding types depending on these builtins to the default type overrides. We now support all modules of the full standard library!
• TypeCheck.Credo.Check.Readability.Specs: an opt-in alternative Credo check which will check whether all functions have either a @spec! or ‘normal’ @spec. (Fixes #102).

Fixes

• The TypeCheck.Builtin module is now actually spectested itself. Some consistency bugs were found and solved as a result.

We’re very near to a stable 1.0 release now.
But that is not all: in the meantime, some great work is being done by @orsinium to increase interoptability with modules which are not part of your own codebase.
In the near future (which will be part of the next release) we’ll be able to extract types from external modules and combine them with the ones explicitly written out using TypeCheck.
Work on this is still in progress; there are some design choices to still be made. If you find this interesting or have opinions about it, please let us know!

WhatsApp Image 2022-06-11 at 8.20.29 AM1200×900 36.1 KB

ElixirConf.EU was a lot of fun!
Being with such a nice group of cool, clever and excited people is a really great way to get new energy to continue any project.
Many people asked questions and gave valuable feedback.

Thank you very much, everyone!

(For who was not there: A video recording of the talk will be released some time later in this year, once the organisers are ready to do so.)

For who wants some more in-depth knowledge on how the library works and could be used, be sure to check out Episode 72 of the Thinking Elixir podcast, in which Mark Ericksen, David Bernheisel and Cade Ward interviewed me about the library !

Version 0.5.0 has been released!

This version adds a number of stability and ‘quality of life’ improvements.

Additions & Improvements

• Adding the option debug: true, wich can be passed to use TypeCheck or TypeCheck.conform/3 (and variants), which will (at compile-time) print the checks that TypeCheck is generating. Example.
• Allow disabling the generation of a typespec, by writing @autogen_typespec false. This will ensure that no typespec is exported for the next @type!/@opaque/@spec! encountered in a module. Example.
• Actually by default autogenerate a @spec typespec for all @spec!'s.
• Code coverage of the test-suite increased to > 85%.

Fixes

• Bugfixes w.r.t. generating typespecs that Elixir/Dialyzer is happy with.
• Fixes compiler-warnings on unused named types when using a type guard.
• Fixes any warnings that were triggered during the test suite before.

Meta

• Moving from Travis CI to GitHub Workflows
• Setting up Coveralls for code coverage.

It was long overdue:
Version 0.4.0 has been released!

This adds two main features:

• Protocol-based types
• Type overrides.

Protocol-based types

This adds supports for impl(ProtocolName). This is a way to use “any type that implements protocol ProtocolName” in your types and specs.

TypeCheck supports this both in type-checks (checking whether a protocol is implemented for the given term), as well as for property-testing generation (generating “any value of any type that implements ProtocolName”):

An example of using protocols in specs:

defmodule OverrideExample do
  use TypeCheck

  @spec! average(impl(Enumerable)) :: {:ok, float()} | {:error, :empty}
  def average(enumerable) do
    if Enum.empty?(enumerable) do
      {:error, :empty}
    else
      res = Enum.sum(enumerable) / Enum.count(enumerable)
      {:ok, res}
    end
  end
end

OverrideExample.average([10, 20])
{:ok, 15.0}
iex(18)> OverrideExample.average(MapSet.new([1,2,3,4]))
{:ok, 2.5}
OverrideExample.average([])              
{:error, :empty}

OverrideExample.average(10)                   
** (TypeCheck.TypeError) At iex:11:
The call to `average/1` failed,
because parameter no. 1 does not adhere to the spec `impl(Enumerable)`.
Rather, its value is: `10`.
Details:
  The call `average(10)`
  does not adhere to spec `average(impl(Enumerable)) :: {:ok, float()} | {:error, :empty}`. Reason:
    parameter no. 1:
      `10` does not implement the protocol `Elixir.Enumerable`
    lib/type_check/spec.ex:156: OverrideExample.average/1

And an example of some generating some data:

iex> require TypeCheck.Type
iex> import TypeCheck.Builtin
iex> TypeCheck.Type.build(impl(Enumerable)) |> TypeCheck.Protocols.ToStreamData.to_gen |> Enum.take(5) 
[
  %{{false, ""} => -1.0},
  #MapSet<[]>,
  -2..2,
  0..3,
  %{:EG => {}, {false} => 1.0, [] => %{-1 => ""}}
]

Type Overrides

From time to time we need to interface with modules written in other libraries (or the Elixir standard library) which do not expose their types through TypeCheck yet.
We want to be able to use those types in our checks, but they exist in modules that we cannot change ourselves.

The solution is to allow a list of ‘type overrides’ to be given as part of the options passed to use TypeCheck, which allow you to use the original type in your types and documentation, but have it be checked (and potentially property-generated) as the given TypeCheck-type.

An example:

      defmodule Original do
        @type t() :: any()
      end

      defmodule Replacement do
        use TypeCheck
        @type! t() :: integer()
      end

      defmodule Example do
        use TypeCheck, overrides: [{&Original.t/0, &Replacement.t/0}]

        @spec! times_two(Original.t()) :: integer()
        def times_two(input) do
          input * 2
        end
      end

Or indeed:

defmodule TypeOverrides do
  use TypeCheck
  import TypeCheck.Builtin
  @opaque! custom_enum() :: impl(Enumerable)
end

defmodule Example do
  use TypeCheck, overrides: [{&Enum.t/0, &TypeOverrides.custom_enum/0}]

  @spec! average(Enum.t()) :: {:ok, float()} | {:error, :empty}
  def average(enumerable) do
    # ... (see first example of post)
  end
end

As this feature is still very new, there are bound to still be some bugs or edge cases in there.
Also, it would be nice to have support by default already provided for all remote types of Elixir’s standard library.
This is something which will be added in the very near future; probably in the next release.

What is next?

A detailed long-term roadmap is available in the Readme.
In the short-term, focus is on the following:

• Improve code-coverage of the testing suite
• Move the CI from Travis to GitHub’s workflows, and test against newer (and possibly some older) Elixir versions
• Add a set of ‘default overrides’ for the common remote types that are part of the Elixir standard library (such as Enum.t(), Range.t(), DateTime.t() etc.).
• Be able to limit the depth of the generated checks, to further increase performance for production environments.