Fork me on GitHub
#clojure-dev
<
2017-07-26
>
alexmiller01:07:13

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

dpsutton03:07:25

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

seancorfield03:07:13

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

seancorfield03:07:54

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

dpsutton03:07:04

ah ok. i thought they all went to Rich

thheller06:07:07

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

thheller06:07:38

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

mpenet06:07:15

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

mpenet06:07:08

one could argue it could/should throw an assertion error

cfleming09:07:27

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

bronsa09:07:52

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

cfleming09:07:55

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

bronsa09:07:27

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

cfleming09:07:29

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

bronsa09:07:10

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

thheller12:07:18

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

thheller12:07:45

since I never noticed the conflicting destructured binding

thheller13:07:50

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

tbaldridge13:07:30

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

alexmiller15:07:39

Doesn't seem like a good check for spec

alexmiller16:07:02

It's also something occasionally done intentionally with _ args

alexmiller16:07:54

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

favila17:07:21

do any linters catch that?

noisesmith17:07:07

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.

hiredman17:07:35

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

favila17:07:33

Yeah basically any args shadowing outside _ is unintentional IMO

alexmiller17:07:57

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

hiredman17:07:38

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

andy.fingerhut19:07:51

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