This is a case I never really thought about - if the key is missing today you'll get nil as the value and since Clojure is a nil punning language it usually does sensible behaviour in your program<p>I know this sounds unreliable but in practise I like a language that defaults to pragmatic code paths so I don't have to stay up at night imagining a million code paths<p>This adds a throwing codepath which is quite drastic so I'm glad people don't build this into programs everywhere - I'd be nice to hear what the team imagine as the use case for this<p>Normally for correctness I'd like to see specs at the boundaries for programs and different test suites for internal behaviours
The problem in my experience is that while nil is a perfectly reasonable default 9/10 times that 1/10 happens often enough and causes major problems that it is worth taking the extra few seconds to write it explicitly in the code to acknowledge that case and that you have checked that it is fine in the 9/10 cases or handle it in the 1/10 case.<p>I have seen multiple major production outages in Golang code because people accidentally read a non-existent map key and used the default value. As a funny bonus in one of those cases we were stumped when debugging because this code had tests, but the tests were also reading the default values out of the map and asserting that "" was in fact a valid textproto (it always is!) so silently testing nothing.<p>So even if defaults are useful 9/10 times that 1/10 is so painful and expensive that it isn't worth it in my experience. The time spent responding to, debugging and fixing those outages far, far outweighed the time saved by the convenient default values in the 9/10 times.
For me: documentation at the "front door" of an interface, especially in that long moment before you decide to add a spec or Malli schema.
This is really the kind of thing you want to fail at compile time which isn’t real possible in a dynamic language like Clojure.
Well it is possible - you can add a user macro that calls into clj-kondo (or anything actually) to check your codebase on compile<p>It just doesn't make much sense to do - most modern developers will be running static analysers through LSP or their editor (knowingly or not) continuously on code change so as to see those errors quicker than re-compiling the program
Unless you use Typed Clojure, which is a library.
<a href="https://github.com/typedclojure/typedclojure" rel="nofollow">https://github.com/typedclojure/typedclojure</a><p>I haven't used it, so I don't know its tradeoffs; but its docs say its types exist at compile time:
<a href="https://github.com/clojure/core.typed/wiki/User-Guide" rel="nofollow">https://github.com/clojure/core.typed/wiki/User-Guide</a>
Some explanations from <a href="https://clojure.atlassian.net/browse/CLJ-2961" rel="nofollow">https://clojure.atlassian.net/browse/CLJ-2961</a>:<p>> Clojure’s idiomatic use of maps has proven valuable, but missing required keys, misspelled keys, and invalid values can lead to failures that do not connect to the actual source of the problem (e.g. NPEs) making diagnosis difficult. At the same time, Clojure lacks a simple inline mechanism for functions to document and check the keys they require and accept. Existing tools either separate those expectations from the function itself or couple data shape and data provision.
This is actually great, and I predict that fans of nil-punning will rapidly discover the joys of actually having errors trigger where the error was introduced rather than propagating through the program.<p>Any news on ClojureScript gaining the feature?
Is it only me or this sounds a bit counter to clojure philosophy?
As a Clojurist the standard pattern for ensuring keys-are-set before doing-something is not-as-elegant-as-this. Clojure is full of macros that do useful things :) Simplifying oft-used patterns into compact representations is very on-brand. Plus, you need this like, all the time.<p>This will eliminate two whole classes of errors:
1) where keys are supplied a value at an undesired nesting-level.
2) where keys are not-yet-set for some other reason.<p>For the many programmers who have to write in checks and verifications themselves for this, this saves quite a bit of time, removing the interruption from coding and restoring the flow of getting logic-to-symbol.
The maps are still open to new keys even if some keys are checked. I think that fits in with how clojure.spec and Malli work already, but in a lighter syntax.
Seems additive to me; no breaking changes, and better control and error messages when opting in for it, seems entirely Clojurely to me.
It's 100% opt-in at the call site and doesn't affect existing code, so no?<p>Many people (including myself) already have checked key variants for maps; this mainly extends the syntax to destructuring too.
Howso?
This is helpful, because practically many functions in the wild have assert-like checks at the top of the function, e.g.<p>`(if-not key1 (throw (Exception ...))`<p>...and pre-conditions, e.g. `:pre [condition1 condition2]` do not run when `<i>assert</i>` is off.
We just updated one of our projects to 1.12.5, but I might push for 1.13 as this could be very useful, although an alpha version might raise questions.
Ah yes, the missing seventeenth way to validate function parameters.
I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.
It's like a light saber instead of a machine gun. Let the bullets come to you.
It'll take a while but now other programming languages look alien to me.
Once you've adopted s-expressions it is hard to go back.
It took about two weeks for me to be able to read it.<p>Might as well have been Russian.<p>Now it's as natural as any other language.
You get over it really quickly once you start actually using it. I find it basically impossible to read Clojure outside the editor in any meaningful sense.