Seeking clarification of dependencies of structs in definitions / typespecs

Questions / Help
1

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?

1 Like
2

The answer is in what the code expands to. %B{} in typespecs has to expand to %{__struct__: B, field1: term(), field2: term(), example: ...}, etc. Therefore, adding or removing any struct field (which reflects on the exported definition of B), requires recompilation. The same happens for %B{} in a function body, we need to expand all fields.

In both cases, inside a function or inside a spec, B.t() addresses this because it encapsulates these concerns into a function, there is no code expansion.

The only exception is %B{example: ...} inside a pattern. The code expands to is %{__struct__: B, example: ...}. So in theory it could be a runtime dependency and a later pass could warn the struct is no longer defined or the field does not exist. But I am not quite sure it is worth special casing around this.

6 Likes
3

Thanks for the reply, very clear.

Ah, so for function body, we need to expand all fields purposes for performance reasons, i.e. %{__struct__: B, field1: term(), field2: term(), example: ...} is faster than C.__struct__(example: x * 2), right?

Only unanswered question is why typespecs function references are not checked by the compiler… Is it because it is deemed to be dialyzer’s responsibility?

4

Correct and correct.

2 Likes