I fear I am missing a few things, but after thinking about the dependencies that structs generate, both in typespecs and in function definition, it looks to me like:

• structs in function definitions should introduce a runtime dependency instead of an export dependency
• structs in typespecs should not introduce an export nor a runtime dependency.
• Example.t() in typespecs should have similar effects as %Example{}

Structs in method definitions

# a.ex
defmodule A do
  @spec foo(%B{}) :: %C{}
  def foo(%B{example: x}) do
    %C{example: x * 2}
  end
end

As far as I understand, compiling the def above currently requires knowing B and C to insure that example is a field, and for no other reason. Am I missing something?

If I am not, why would the check that example is a field not be done at build time, same as when we check that SomeModule.foo() exists?

Structs in typespecs

The @spec above introduces an export dependency on B & C.

I presume this is for the same reason, i.e. if we were to write additional spec for the fields (we basically never in practice though), then this would generate an error when compiling if keys are invalid.

Again, am I missing some other reason?

If not, then that check could also be done at build time instead, or not at all (like Example.t() in typespecs)

It seems clear to me that even a runtime dependency would actually be too strict, because it could still introduce useless transitive compile time dependencies. These would always be “false alarms”, i.e,. would trigger a recompilation that wouldn’t change the output.

This is rarely important for typespecs of functions because ultimately the implementation will typically have runtime dependencies on these modules, but for field declarations or @callback, this can make a big difference.

Type references in typespecs

I don’t know why there is no checking of the validity of types used like Example.t(). Maybe the idea is to rely solely on Dialyxir?

I am surprised that changing Example.t() to %Example{} in a typespec would be so different as it is current. It seems clear to me that both forms should have the same effect on the dependency graph (i.e. none) and checks (i.e. either a build-time check for validity, or none and we rely on dialyxir).

At first I tought that it might be useful to introduce a lower type of dependency (say “buildtime dependency”) for %Example{} and Example.t(), that would not count for transitive dependencies, but I can’t see the point of exposing it and might just be more confusing than anything.

Reducing export dependencies to either runtime dependencies, or to none at all seem like a clear gain. What am I missing?