HN Explorer

15 comments

[ 4.8 ms ] story [ 45.1 ms ] thread
slifin
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

sokoloff
> if the key is missing today you'll get nil as the value

You can add a third parameter to override the nil if detecting the missing key matters.

(You almost surely know this, but not all HN commenters will.)

  user> (:bar {:foo 1})
  nil
  user> (:bar {:foo 1} :missing)
  :missing
bjconlan
Yeah I'm with you, this feels like a case for assertions & not a new core feature. Perhaps I'm missing something because it was promoted by Michael Fogus and has been ratified by those who would know (Alex I'm assuming). To me it doesn't pass the test of necessity as something needed at the core but at least it feels somewhat ideomatic.
ndr
Is it only me or this sounds a bit counter to clojure philosophy?
ajmoon
I agree it feels a bit counter to the philosophy of Clojure. It's adding new syntax to the language for map destructuring only (that will need to be implemented in cljs and other runtimes for consistency) and it's a purely runtime check as we don't know the map's keys at compile time. I don't see what new kind of safety it adds that's not achievable with existing solutions such as :pre or doing an assert inline.

I feel there are better solutions to this problem that already exist, such as using spec/malli and validating the value properly rather than just checking for presence.

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

moomin
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?

temporallobe
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.
exabrial
I love the idea of clojure and perfect immutability, but holy crap I cannot grok the syntax. My C-trained brain explodes.
thom
Ah yes, the missing seventeenth way to validate function parameters.
pgt
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.

IceDane
Slowly but surely dynamic programming proponents discover the value of statically verifiable correctness. Who'd have thought?
lastofus
Snarkiness aside, this is hardly a static type check. This appears to be a runtime argument check, somewhat akin to the following python:

  def foo(*, a, b): return a+b
which errors out at runtime if `a` or `b` are omitted, despite being keyword arguments which are usually optional.
beders
Oh we know. That's why static types are a la carte in Clojure. You can have them if you really really want them.
geokon
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