[core.specs] ::keys spec conflicts with destructuring spec
Description
As a consequence of the destructuring specs being implemented in terms of `s/keys`, defining a spec for `::keys` or `::strs` is problematic at the moment, because it will conflict with trying to use `::keys` for destructuring:
This feels like an implementation detail leak.
Environment
Activity
I also just ran in to this problem. Just wanted to say that I'd like to see a fix, but I'm not quite sure about the proposed solution. Or, at least, the name "closed?" seems to imply a non-extensible map, when in reality the flag more or less means "not a map that participates in the global keys system", for which I do not have a better name suggestion.
The proposed patch is a non-starter. I have some ideas on how to address this, but just haven't gotten around to working on it yet.
Removed proposal and patch from the ticket as we will not be going this direction. Captured here for reference:
"The attached patch implements a proposed solution to this issue, by adding a `:closed?` option to `s/keys` and using it for the destructuring spec. If `s/keys` is used with `:closed?` set to true, `conform` will only validate declared specs as opposed to the default behaviour of `s/keys` of validating all namespaced keywords with existing specs.
After this patch, the above example runs fine and usages of `s/keys` without `:closed?` set to true will validate against `::keys` as per current behaviour.
Patch: close-destructuring-keys-specs.diff"
Assignee
Reporter
Approval
Patch
Priority
