Clojure 1.13 adds support for checked keys

(clojure.org)

96 points | by FelipeCortez 3 days ago

5 comments

  • slifin 1 hour ago
    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

  • moomin 38 minutes ago
    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?

    • swannodette 21 minutes ago
      Working on it :)
      • embedding-shape 11 minutes ago
        Amazing! What are the most interesting areas for ClojureScript in the future, if you don't mind me asking for some casual semi-serious prediction?

        Thanks for everything you've done for Clojure and ClojureScript, I'd surely have dropped programming as a whole if I didn't discover Clojure and ClojureScript at the time I did.

  • hk__2 46 minutes ago
    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.

  • temporallobe 31 minutes ago
    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.
  • ndr 1 hour ago
    Is it only me or this sounds a bit counter to clojure philosophy?
    • summarybot 25 minutes ago
      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.

      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.

      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.

    • embedding-shape 10 minutes ago
      Seems additive to me; no breaking changes, and better control and error messages when opting in for it, seems entirely Clojurely to me.
    • rads 51 minutes ago
      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.
    • erichocean 59 minutes ago
      It's 100% opt-in at the call site and doesn't affect existing code, so no?

      Many people (including myself) already have checked key variants for maps; this mainly extends the syntax to destructuring too.