I'm sure this will all be revealed in time (maybe in Rich's conj talk 🤞) but I've been wondering about how the destructuring features will eventually tie into spec. Like if you were to just move from using spec for validation of inputs to using the new destructuring directives as they are now, you would lose:
• ability to validate the values of individual "leaf" attributes
• ability to generate data (for testing, etc)
• documentation benefits, the ability to express global definitions of data structures used throughout a system
Like, I see how the new destructuring somewhat replaces s/keys "anonymously" and how the forms can express everything spec2's selections could, and i see how keyspaces can replace schemas but there's still a gap to get all the benefits of spec, and I'm curious how it gets filled.
I think the two approaches are complementary. You can use both. The https://youtu.be/YR5WdGrpoug?si=uFgnovHnO_bIpqhG talk mentions some of the ideas. One of the challenges with spec is that whether or a not a key is required depends on the context. The new destructuring syntax is about saying which keys are required for a particular context.
There is a path that connects the two, not sure we will get there in 1.13. Rich might talk about it in his talk
The biggest open question post maybe not was how to talk about structure, especially nested structure and connect it to vocabulary. The schema and select stuff in spec 2 was a stab at that, but it stalled at connecting in a natural way at the code signature. The new stuff in 1.13 is recognizing that we already have a way to talk about structure in function signatures and elsewhere via destructuring and we can leverage that to specify selection.