This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-02-12
Channels
- # adventofcode (6)
- # beginners (148)
- # boot (5)
- # calva (1)
- # cider (10)
- # cljdoc (10)
- # cljs-dev (8)
- # cljsrn (10)
- # clojure (180)
- # clojure-dev (24)
- # clojure-europe (2)
- # clojure-finland (1)
- # clojure-italy (32)
- # clojure-losangeles (1)
- # clojure-nl (40)
- # clojure-spec (10)
- # clojure-uk (44)
- # clojured (4)
- # clojurescript (88)
- # community-development (33)
- # core-async (7)
- # cursive (19)
- # datomic (98)
- # duct (3)
- # events (1)
- # figwheel-main (10)
- # fulcro (62)
- # leiningen (23)
- # luminus (18)
- # off-topic (19)
- # pedestal (6)
- # re-frame (46)
- # reagent (21)
- # ring (17)
- # ring-swagger (3)
- # shadow-cljs (94)
- # slack-help (9)
- # spacemacs (14)
- # sql (1)
- # testing (4)
- # tools-deps (14)
10:07 $ clj
Clojure 1.10.0
user=> (defn foo [{:key [lol]}] )
Syntax error macroexpanding clojure.core/defn at (REPL:1:1).
{:key [lol]} - failed: vector? at: [:fn-tail :arity-n :bodies :params] spec: :clojure.core.specs.alpha/param-list
({:key [lol]}) - failed: Extra input at: [:fn-tail :arity-1 :params] spec: :clojure.core.specs.alpha/param-list
user=>
I would have expected something that told me that :key
was not a valid destructuring thing.
@slipset Interesting. I think you can already experiment with this yourself, by overriding the specs here in your REPL: https://github.com/clojure/core.specs.alpha/blob/master/src/main/clojure/clojure/core/specs/alpha.clj#L89
In short, not easily - the keys of the destructuring map are symbols, vectors, or a set of different known or open key sets
Maybe it would be possible to write a predicate and then s/merge a map spec that narrowed the keys to that. I’ve messed with all that a bit, never got happy with it
Speaking about core specs: https://github.com/clj-commons/secretary/pull/105#issuecomment-462940480 I’ve seen this error more than once.
Is there a question?
Not really a question. More an observation that these specs forbid something that used to work before and occurred in people’s code.
that has never worked. before it just silently had no effect, now it tells you.
ah right! in this case the import wasn’t even needed: https://github.com/joelkuiper/yesparql/commit/b7e9f30b606d9ef043c95bb565d3139a8ec61549 that set me on the wrong foot 🙂
that is true of literally 100% of these (because they previously had no effect)
would there be any interest to extend the integer regex to allow for an l
suffix to require Long in the same way you can add an N
to require a BigInt? Not often used but coworker was surprised by the type promotion to BigInteger
seems to align with known jvm syntax but also dangerously close to the "who would ever use this" line? Just wondering
What problem are you trying to solve?
i think it was more flashbacks from silent type promotion in php. We were reading the source after a discussion in #beginners and he was surprised that he couldn't guarantee the return type of the literal. IE, all theoretical and no actual problem at hand
That sounds like a pretty weak problem statement :)
Any objections to adding @zulip-mirror-bot to this channel to mirror messages to Clojurians on Zulip > slack-archive stream > clojure-dev topic?
(mostly I've just been adding it to channels here but I figured I'd ask for this channel)
Mind you, @logbot is already so I guess it's about the same thing. I'll add it. If anyone objects, I can remove it again 🙂