Increasing compilation times is a very good trade-off for not doing it at compile time 
It’s not an issue for my pet app, but would be nice to see future improvements here
Exadra37
0
Exadra37
Doesn’t this make the library slow at runtime? If yes I prefer to pay the toll at compile time
1
josevalim
Creator of Elixir
IvanR
In Domo 1.2.2 there is a verification that a struct built at compile time matches its type. That works as the last step of compilation with the library’s custom compile task 
The verification works for given modules as follows:
defmodule Planet.Bar do
use Domo
defstruct [:name]
@type t :: %__MODULE__{name: String.t()}
end
defmodule Foo do
use Domo
alias Planet.Bar
@default_name :coyote
defstruct [bar: Bar.new(name: @default_name)]
@type t :: %__MODULE__{bar: Bar.t()}
end
➜ ~ mix compile
Compiling 1 file (.ex)
Domo is compiling type ensurer for 2 modules (.ex)
== Compilation error in file lib/foo_bar.ex:15 ==
** Failed to build Planet.Bar struct.
Invalid value :coyote for field :name. Expected the value matching the <<::*8>> type.
➜ ~ echo $?
1
And with:
@default_name "Coyote"
➜ ~ mix compile
Compiling 1 file (.ex)
Domo is compiling type ensurer for 2 modules (.ex)
➜ ~ echo $?
0
There is no Macro expansion during the Foo and Bar modules compilation with Elixir. Their environments are temporary stored for the :domo_compiler step. During the Domo compiler step, the expansion works like Macro.expand_once(Bar, foo_env) to get the full name of the Planet.Bar module. Then type ensurer modules code is generated and compiled, and Bar fields stored from the new call are ensured to match the type. Then Domo compiler step drops environments and compilation finishes.
It seems that it shouldn’t be additional compile/runtime dependencies for Foo and Bar modules with the process described above 
P.S. At the application’s runtime, Foo.new/1 and Bar.new/1 ensures that input fields match the type themselves or raises on mismatch.
5