[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

None

Activity

Show:
Brandon Bloom
January 10, 2017, 11:36 PM

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.

Alex Miller
January 11, 2017, 2:35 PM

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.

Alex Miller
January 11, 2017, 2:37 PM

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

Alex Miller

Reporter

Nicola Mometto

Approval

Triaged

Patch

Code

Priority

Major
Configure