Getting the @type module attribute

Yeah, you can’t get @type, @spec, @callback and friends because they have special semantics. Usually, what is stored in a module attribute is evaluated, if you do @foo 1 + 1, the value of @foo is the result of 1 + 1. For typespecs, we actually receive an AST that we process, and returning that would leak some implementation details.

Interesting use case!

Currently, when you add @type-annotations inside the defconfig, they will end up being shown in the documentation just as if they were written outside of the defconfig.
So t YourModule.floors_to_sweep would work in IEx, and in the compiled HTML documentation, the type would also be listed.

If you want to fully link to a type, what about writing a parser function and adding a @spec to that one? The field documentation will link to its parser function’s documentation, and in that way you can keep the semantics together. (The other advantage is that you can re-use the same type/parser for multiple fields).

Thanks for your answers.

@Qqwy: not sure to understand and if it’s the same use case . Mine is mainly about documenting hundreds (if not more) configuration options including many callbacks with most of the time different signatures, and linking between them (config option ↔ type), and also to help dialyzer with detecting type errors. Nice lib by the way!

I think this part is already covered by the existing functionality. Every module that uses defconfig will have, for every field in the documentation, the following part in their docs:

Example here.

This is indeed not something that Specify currently helps you with. It definitely would be interesting to automate the generation of a ‘config typespec’ in some way. Maybe the field types can be inferred from the parser function’s spec, and we can then define a type for the config struct as a whole. …

Thanks!

I’ve tried it and it’s somehow difficult to generate some specs because of the special syntaxes of @type and @spec (::, etc.). See also: Dynamically generate typespecs from module attribute list

I’m fairly certain this is what Code.Typespec is meant to be used for.
We could (as long as the parser function is readable as an invocation of a certain MFA) call Code.Typespec.fetch_specs(module), find the appropriate function’s spec in the response, and then use Code.Typespec.spec_to_quoted to turn it back into Elixir AST, which, assuming that it has the format some_fun(maybe, some, arguments) :: {:ok, result_type} | {:error, problem} means that we should be able to extract the result_type from here.
The one thing I haven’t figured out yet is how to disambugate remote types from local and built-in ones.

I’m now trying to get the @moduledoc module attribute in a __using__ macro but in:

      {line_number, existing_moduledoc} =
        Module.delete_attribute(__MODULE__, :moduledoc) || {0, ""}

      Module.put_attribute(
        __MODULE__,
        :moduledoc,
        {line_number, existing_moduledoc <> additional_doc})

Module.delete_attribute/2 always returns nil (although the @moduledoc is set) and Module.put_attribute/3 doesn’t set it (nothing in generated doc).

Is there an exception with @moduledoc? I suspect it is not set yet when calling Module.delete_attribute/2. Also Module.put_attribute/3is later erased by the plain @moduledoc (I’ve tested it - no @moduledoc in the target module results in additional_doc being displayed).

Is this still true today? Or there are ways to get the type specs for functions now.

Afaik there is still no public API for doing so.