Is it overprotective to have defaults validation with TypedStruct and TypedEctoSchema?

Dear community,

There are lovely TypedStruct by @ejpcmac and TypedEctoSchema by @bamorim libraries to define structs in combination with t() types.

Using them, I missed the validation of default values conformance to t(). That validation seems good because initial default values defining the app’s state can drift from the type definition later as the code evolves. That, in turn, can confuse the local thinking about what’s correctly defined the value or the type?

To address this, I’ve added the compile-time defaults validation feature to the Domo library. That works for any struct that has a t() type defined. And can be activated by adding use Domo like the following:

defmodule Order do
  use TypedStruct
  use Domo

  typedstruct enforce: true do
    field :id, non_neg_integer()
    field :items, [String.t()], default: []
  end
end

That gives the compile-time error highlighting the issue immediately

Compiling 1 file (.ex)
Domo is compiling type ensurer for 1 module (.ex)

== Compilation error in file lib/functional_core_struct.ex:55 ==
** A default value given via defstruct/1 in Order module mismatches the type.
"Invalid value nil for field :id of %Order{}. Expected the value matching the non_neg_integer() type."

And adding default: 1 option to field :id or changing its type to non_neg_integer() | nil leads to successful compilation.

How do you see it can be worthful to your projects?