In spec2, is it possible to use s/conform on a vector parsed via a sequence matcher like vcat and then getting back a vector via s/unform?

From the documentation, it does not look like it would work.

Yes, it works now

With s/catv

What documentation are you referring to?

@alexmiller I had this impression after reading those 2 places: • https://github.com/clojure/spec-alpha2/wiki/Differences-from-spec.alpha#scat which hints that vcat uses s/and- , • and https://github.com/clojure/spec-alpha2/wiki/Differences-from-spec.alpha#nonflowing-sand--new which does not say that s/unform validates other preds in a s/and-.

The example about s/vcat may potentially confuse people w.r.t. s/catv .

Thx, I’ll update that

heya

are there any breaking changes one should be aware of between 0.1x and 0.2.x for spec?

I'm updating a project's cljs 1.10.520 to `1.10.597` , and my production build now fails when loading something spec related

| TypeError: Cannot read property 'prototype' of ...
                                                V
$APP.$cljs$spec$alpha$t_cljs$0spec$0alpha62946$$.prototype.$cljs$spec$alpha$Spec$gen_STAR_$arity$4$ = $JSCompiler_unstubMethod$$(6, function($_$jscomp$256$$, $overrides$jscomp$11$$, $path$jscomp$62$$, $rmap$jscomp$11$$) {
  return $APP.$cljs$core$truth_$$(this.$gfn$) ? this.$gfn$.$cljs$core$IFn$_invoke$arity$0$ ? this.$gfn$.$cljs$core$IFn$_invoke$arity$0$() : this.$gfn$.call(null) : $APP.$cljs$spec$alpha$re_gen$$(this.$re$, $overrides$jscomp$11$$, $path$jscomp$62$$, $rmap$jscomp$11$$, $APP.$cljs$spec$alpha$op_describe$$(this.$re$));
});

doesn't seem to affect the normal build though

Have folks ever used spec to define a transformation between namespaced, clojure maps to another format? My use case is creating maps in clojure but transforming them to JSON, and I don't want for there to be coupling between my clojure key names (ie. namespaced keywords) and my JSON maps (which may even contain keys that aren't representable as clojure keywords)

I was hoping to have the resulting key name as part of the spec so as to keep all of the relevant information about that attribute in one place, but perhaps this is best done outside of spec?

you can store a lookup from qualifiedkey -> key in a sibling database, doesn't have to be in the spec registry