video will hopefully be out by next week, but I don’t really have any control over that

Is there anything to the fact that this is copyright both Alex and Rich?

@dpsutton The copyright on each contrib depends on who wrote the code -- and the CA co-assigns copyright to Rich.

For example https://github.com/clojure/java.jdbc#copyright-and-license is me and Stephen Gilardi (and under the CA Rich has co-rights, although they're not called out there directly) @dpsutton

ah ok. i thought they all went to Rich

(defn x [{:keys [foo]} foo]
  foo)
=> #'user/x
(x {} 1)
=> nil

just noticed this while refactoring some code, is it just me or does that seem wrong?

I guess it could be filed under garbage in -> garbage out

one could argue it could/should throw an assertion error

That’s expected, I think, right? (:foo {}) returns nil

I think the confusion is from foo being shadowed from a previous arg

Or do you mean that you’re binding foo twice?

Right

this has been brought up already a while ago and IIRC it was considered GIGO

Interesting, I guess the destructuring is performed after the method call, so it will shadow the actual param.

yeah, that expands to something like (defn foo [map__1 foo] (let [foo (get map__1 :foo) ..))

Right

a warning would be nice, took me 30min to figure out why the heck I was getting nil where I clearly wasn’t passing nil

since I never noticed the conflicting destructured binding

@cfleming maybe a fix in cursive since it technically highlights the incorrect foo 😉

Seems like that would be fairly easy to catch with spec at some point.

Doesn't seem like a good check for spec

It's also something occasionally done intentionally with _ args

So I would say it's garbage in, semantically consistent values out

do any linters catch that?

I seem to recall warnings from eastwood about locals shadowing namespace level or clojure.core values, but intentional shadowing is common enough in local scope that I think the warnings would give you a lot of false positives.

sure, but in this exact situation it isn't just locals shadowing, it is args shadowing each other, which I think outside of _ is extremely rare and pretty much always unintentional, so seems like a good candidate for linter. the linter would have to check before macro expansion so it would need to understand destructuring

Yeah basically any args shadowing outside _ is unintentional IMO

not always

I mean, I think you’re probably right 99% of the time but people do a lot of weird stuff

right, but the bar is different for a linter than for the language

agreed

@thheller I don't think Eastwood warns about that case today, but I've created an issue with your example to remind us of the usefulness of such a warning.