Typespecs: function types

@type task :: (any -> {:ok, pid} | {:error, term})

maybe?

Or the general practice is to define the task type as an alias to fun() and use typedocs to describe what is expected from the task type.

Dialyzer (Dialyxir) doesn’t process typedocs - so being as specific as possible on the spec is inherently more useful.

Great, many thanks. I think the syntax is worth mentioning explicitly in

That’s primarily a tutorial. The standard library documentation has more complete coverage.
Typespecs, i.e.

                                  ## Functions
  | (... -> type)                 # any arity, returns type
  | (() -> type)                  # 0-arity, returns type
  | (type1, type2 -> type)        # 2-arity, returns type

BTW, is there a way to specify the expected type of a named function when it is passed as module, atom, args as in, say, Task.async

Yup, I had a quick look actually, but totally missed it. I think the syntax deserves a small section with a header “Function types” or something which should make it easier to find.

How would static analysis utilize that information given that the result type for await/2 and apply/3 is entirely dependent on information that is generated completely at runtime?

I guess you could wrap an apply in a function that has a specified result type in order to let Dialyzer know what you expect - but there are no guarantees and you would still need to inspect the result type at runtime and crash if your expectation isn’t met to catch the problem at the earliest possible time.

Remember that Dialyzer is only performs success typing - it will only alert you when it can prove that you are wrong - otherwise it assumes that you know what you are doing.

I split out the functions types in a separate section in typespec docs (PR) and would be happy to add a paragraph on the syntax in the Getting Started guide.

Well the module can be very well specified statically. In that case the static analysis can be done to the extent that the function’s result type does not depend on the argument types/arity. For instance for functions returning pids/ports the arguments might not be really relevant.

I can also see that, in principle, one could define module types by specifying the behaviours they implement. Is that wrong?

Typespecs are also useful for humans besides being useful for static analysis.