The docs are clear that the test occurs before the bindings:
(doc if-let)
-
clojure.core/if-let
([bindings then] [bindings then else & oldform])
Macro
bindings => binding-form test
If test is true, evaluates then with binding-form bound to the value of
test, if not,
On Thursday, January 31, 2013 1:49:40 AM UTC+1, Sean Corfield wrote:
> but now that you've posted this, I
> can see some potential for confusion when folks first encounter
> if-let... Presumably the same confusion could arise for when-let?
>
yes, this is the confusion that you can incur in.
On Wednesday, January 30, 2013 8:51:47 PM UTC+1, Gary Verhaegen wrote:
> For your particular use-case, what you want is more along the lines of
>
> (if-let [errors (:password (fn-returning-errors))]
> ...)
>
yes, precisely!
mimmo
--
--
You received this message because you are subscribed
Interesting to see this interpretation of if-let... I'd always read it
as "if the condition is truthy then let the binding be the condition
and evaluate the first expression else just evaluate the second
expression". Since the binding could create multiple named values (in
general), I'm not sure ho
Perhaps I've been a little bit rude with if-let, but I really do not see how
(if-let [{erros :email} (function-returning-errors email password)]
true
false)
is not misleading. I now that the tested value is the one returning from the
function call and not the value assigned to er
If-let does the right thing. What would your intuition expect for
(if-let [{a :a b :b} {:a 1 :b nil}]
true
false)
For your particular use-case, what you want is more along the lines of
(if-let [errors (:password (fn-returning-errors))]
...)
On Wednesday, January 30, 2013, Ben Smith-
I find it helpful to view if-let as a minor variation on if, with the only
difference being that you choose to bind the results of the test-expression
to some name(s). if-let doesn't care about the values bound to the
variables named in binding-target (which might be an arbitrarily complex
destruct
that means never use if-let with sequential destructoring, which brings me to
say: never use if-let, because I don't' like to remember such thing while
coding and then become crazy to catch my error because of a misleading language
feature.
mimmo
On Jan 30, 2013, at 10:32 AM, James Xu wrot
Agree with you that it is very misleading when using map-destructure in
if-let, the same applies to sequential-destructure:
user=> (if-let [[_ x] [1 nil]] true false)
true
On 13-1-30 下午5:23, "Mimmo Cosenza" wrote:
>Uhm, I do not agree.
>
>Suppose tha you have a function returning a map of err
ah, compare
> (if-let [{errors :email} (function-returning-error email password)]
>true
>false)
with
(let [{errors :email) (function-returning-errros email password)]
(if errors
true
false))
I'm not saying that if-let is wrong, I'm saying I would never use in such a
Uhm, I do not agree.
Suppose tha you have a function returning a map of errors (a valip validator
lib real case) like the following
{:email ["Email can't be empty"] :password ["Password can't be empty"]}
If I want to select just the email errors I would write something like that
(if-let [{erro
>From the expansion we can see that if-let determine the result based on
the second param, in your case: {:key2 "a string"}, not the local binding
you assumed(key1), and
I think it is reasonable, for example, if we have the following code:
(if-let [{key1 key2} {:key2 "a string"}]
true
false)
12 matches
Mail list logo
