Clark Lindsay

> Did you try not generating maps with empty blueprints? i believe i did, but i don’t see it in my notes. i’ll do it again just to be sure

i just tried ensuring that no empty-map blueprints are generated by matching on `%{}` and returning a K-V schematic like: `Schematic.map(keys: Schematic.nullable(nil), values: Schematic.nullable(nil))`, but that fails the property very...

maybe i'm not thinking straight at this point in my day, but it seems to me that the property just doesn't hold as soon as you mix `oneof/1` with the...

naively, i guess you could reduce over all of the schematics in a `oneof` and return the result of the unification that maintained the most data in the input? just...

hm, yeah. we might need a lot more info about the schematic than we currently have. alternatively, once you call `unify` for one of the `oneof` schematics, and it's successful,...

> alternatively, once you call `unify` for one of the `oneof` schematics, and it's successful, and it's a map, couldn't we just hold onto that value and wait and see...

i see how it's failing, but i'm having a hard time working out how to adjust the tests. i see it in three-ish ways: - the current property is replaced...

i just roughed out a quick and dirty version where i left everything the same except i ensured that when a `list(...)` schematic is created from data during generation, and...

i was wrong on that second assumption, actually. very wrong. the property fails pretty quickly when we allow any `map/1` schematics that use a "blueprint" as part of the `oneof/1`...