Precise typing of embeds

Currently strukt typing embeds_one :foo, Foo's type as Foo.t(), embeds_many :foos, Foo as [Foo.t()]:

strukt/lib/typespec.ex

Lines 72 to 77 in 2b6c643

	|> Enum.map(fn
	{name, %{type: :embeds_one, value_type: type}} ->
	{name, compose_call(type, :t, [])}
	{name, %{type: :embeds_many, value_type: type}} ->
	{name, List.wrap(compose_call(type, :t, []))}

it couldn't handle situations like

• :foo field could be null which type should be Foo.t() | nil,
• :foos could be nil, but element couldn't: [Foo.t()] | nil
• :foos could be nil, element's could be nil too: nil | [Foo.t() | nil]

any idea for handle these cases?

[bitwalker]

We can probably generate a type like Foo.t() | nil in cases where the field is known to be optional easily enough. An embeds_many should always be a list though, i.e. nil is violating the contract of the schema. If we're getting nil in those fields as a result of something strukt is doing, then we should certainly fix that (i.e. if we're generating default values which are nil rather than []. Likewise, embeds_many with a nil element doesn't make sense, as you either have an empty list, or a non-empty list of valid records, not a list of possibly-invalid records. As far as I know, it isn't possible to express a schema that permits nil records in an embeds_many field anyway.

Do you have some specific examples for the embeds_many cases? That may help demonstrate the issue there better and give me some ideas on whether or not its something we can address.

thank you for your rapid reply!
The embeds_many case is derived by thinking the embeds_one case, so I don't have example for it. but sth similar is graphql's combination of list and non-null https://graphql.org/learn/schema/#lists-and-non-null