Hey!
I started working on dry-rails recently and this is the place where we can add proper ActiveModel/ActionView support. I’d much rather do it there then to expand functionality of dry-initializer because it is already a complex library and it sits in the very core of other libraries, including rom-rb.
When it comes to structs, schemas and validation what’s recommended is to define validation schemas (either using dry-schema or dry-validation, depends on what you need) and then infer structs from it. Doing it the other way around (which I know lots of people want to do because it feels more natural, but it’s…wrong 
) is problematic because there’s no direct translation that can be applied in all of the possible cases, whereas with schema => struct you can translate that 
% with no limitations.
There are a couple of missing parts now:
- no dry-schema => dry-struct conversion API - this can be implemented easily, we already implemented generating dry-struct from rom-rb’s database schemas and we know it’s a simple thing to do
- no support for setting default values - this needs some discussions. Maybe it makes sense to have it as a dry-schema extension. Some quick PoCs should give us answers.
To answer your question:
Have we thought about adding an “extension” to dry-initializer that would record the compatible portions of
paramandoptionarguments as a schema? Even just the names and types?
No, because, like I mentioned, it is not recommended to generate validation schemas from structs and dry-initializer is already complex enough. We encourage the exact opposite because structs are meant to represent valid data all of the time.
Let me know what you think. We can add support for default values and generating structs from schemas to main dry-rb libraries and then implement rails-specific bits in dry-rails. I think a lot of people could benefit from such an effort and it’s not a difficult thing to do 