Fork me on GitHub
#clojure-spec
<
2020-04-18
>
Joe12:04:57

Is this the correct way to spec a non-empty collection?

(s/def ::things (s/coll-of ::thing :min-count 1))

shooit13:04:19

That would do it. The other thing that some to mind is from the sequential specs: s/+. It depends on context which is preferred. Just a non-empty collection of things? Your s/coll-of solution is it. A non-empty sequence of things as part of a larger pattern? Look to the sequential specs for their regex like functionality.

๐Ÿ‘ 4
prnc17:04:15

Spec rationale quote Iโ€™m pondering > Invariably, people will try to use a specification system to detail implementation decisions, but they do so to their detriment. The best and most useful specs (and interfaces) are related to purely information aspects. https://clojure.org/about/spec#_informational_vs_implementational Trying to get clear on the distinction โ€” what would be the canonical example of the offending type of use and how far you can push the boundary so to speak? Is this mostly about trying to enforce implementation a la types (an thus cussedness/rigidity etc.) ?

Alex Miller (Clojure team)18:04:21

Clojure core functions are a good example

Alex Miller (Clojure team)18:04:58

You can spec a function as talking PersistentVector (bad, concrete, may change) or as satisfying vector? or seq? or coll? or sequential? (depends on the fn of course)

๐Ÿ™ 4
Alex Miller (Clojure team)18:04:54

And itโ€™s common to try to spec what exactly it does now vs leaving open for future