Currently, EEP 48 supports a signature field, which is a list of binaries. The signature is pre-rendered. This means tools rendering the documentation only has to concern themselves with printing each line individually.
However, this definition of the signature is not enough for IDEs, which would most likely need to know each argument name and their type, as well as the return type, individually. We should discuss if adding this information is within the scope of EEP 48 and how to effectively add it.
For example, one immediate complication of showing args and return types, is that typespecs in Erlang/Elixir may have multiple clauses, which means there is not a value to show per argument, but multiple of them. Both edoc and Elixir support this style, but not Erlang/OTP XML (afaik).
Currently, EEP 48 supports a signature field, which is a list of binaries. The signature is pre-rendered. This means tools rendering the documentation only has to concern themselves with printing each line individually.
However, this definition of the signature is not enough for IDEs, which would most likely need to know each argument name and their type, as well as the return type, individually. We should discuss if adding this information is within the scope of EEP 48 and how to effectively add it.
For example, one immediate complication of showing args and return types, is that typespecs in Erlang/Elixir may have multiple clauses, which means there is not a value to show per argument, but multiple of them. Both edoc and Elixir support this style, but not Erlang/OTP XML (afaik).