Birbla

Discussion summary

Clojure 1.13 introduces support for checked keys, enabling runtime argument validation. Developers see it as a helpful addition, though some note it’s not static typing. The syntax remains challenging for newcomers but becomes more familiar over time.

What the discussion says

  • Some see it as a useful runtime check, similar to assertions.
  • Others highlight the difficulty in reading Clojure syntax initially.
  • Many users mention a learning curve but eventual familiarity.
  • The update is considered beneficial for code correctness.
“This is helpful, because many functions have assert-like checks.”
— pgt
“It took about two weeks to read Clojure syntax comfortably.”
— erichocean

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • This is helpful, because practically many functions in the wild have assert-like checks at the top of the function, e.g.

    `(if-not key1 (throw (Exception ...))`

    ...and pre-conditions, e.g. `:pre [condition1 condition2]` do not run when `assert` is off.

    by pgt
  • 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.
    by temporallobe
  • I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.
    by exabrial
  • Is it only me or this sounds a bit counter to clojure philosophy?
    by ndr
  • 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.

    Any news on ClojureScript gaining the feature?

    by moomin
  • Some explanations from https://clojure.atlassian.net/browse/CLJ-2961:

    > 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.

    by hk__2
  • One thing to note that's maybe less obvious is that you can destructure some keys with the check and others without. This makes the function interface a bit self-documenting. At a glance you see that the username is required and other parts are maybe not.

        (defn my-function
      [{:keys! [username]
        :keys  [firstname
               lastname]}]
      (do-stuff username
                firstname
                lastname))
    A minor downside is that now it seems `nil` is even more overloaded b/c you can explicitly pass in a nil and give it a special meaning. This generally cascades in to messyness (better to have a special key like `:missing-username`).

    Feels like throwing an error on nil would have been better/simpler? But I'm sure there's an angle I've not considered

    by geokon
  • 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

    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

    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

    Normally for correctness I'd like to see specs at the boundaries for programs and different test suites for internal behaviours

    by slifin

Explore Birbla archives