THAT part I knew. I still haven’t tried out this rc yet but does the type system now warn if both sides aren’t bools? That always sorta bugged me.
sodapopcan
jswanner
Going by what @slouchpie shared, I believe it warns if the left side is a boolean when || is used as or can be used instead. I tried to recreate that warning but failed to do so
1
sodapopcan
jswanner
My apologies, I read your “aren’t” as “are”: “both sides are bools”
That said, the Elixir docs for or explicitly show a use where the right hand side is not a boolean. In guards, or uses Erlang’s orelse, in the Erlang docs they have the following:
Before Erlang/OTP R13A,
Expr2was required to evaluate to a Boolean value, and as a consequence,andalsoandorelsewere not tail-recursive.
0
jswanner
evadne
[Question] try with many independent problems only warns once. On current main (b58e84352), the behaviour of try’s diagnostics changed; once one try alternative sets context.failed, later independent alternatives stop reporting diagnostics:
1. Two rescue bodies with independent bad calls:
defmodule A1R1 do
def f do
try do
raise "oops"
rescue
_ in RuntimeError -> String.length(1)
_ in ArgumentError -> String.length(2)
end
end
end
v1.19.5 (d33fd8e41):
(none)
current main / v1.20 RC (b58e84352):
warning: incompatible types given to String.length/1:
String.length(1)
given types:
-integer()-
but expected one of:
binary()
└─ a1_r1.ex:6:35: A1R1.f/0
2. Failed rescue body followed by undefined exception head:
defmodule A1R2 do
def f do
try do
raise "oops"
rescue
_ in RuntimeError -> String.length(1)
e in UnknownError -> e
end
end
end
v1.19.5 (d33fd8e41):
warning: struct UnknownError is undefined (module UnknownError is not available or is yet to be defined). Make sure the module name is correct and has been specified in full (or that an alias has been defined)
└─ a1_r2.ex:7:9: A1R2.f/0
current main / v1.20 RC (b58e84352):
warning: incompatible types given to String.length/1:
String.length(1)
given types:
-integer()-
but expected one of:
binary()
└─ a1_r2.ex:6:35: A1R2.f/0
3. Failed rescue body before catch body:
defmodule A1R3 do
def f do
try do
throw(:x)
rescue
_ in RuntimeError -> String.length(1)
catch
:throw, :x -> Integer.to_string(:atom)
end
end
end
v1.19.5 (d33fd8e41):
warning: the call to integer_to_binary/1 will fail with a 'badarg' exception
└─ a1_r3.ex:8:29
warning: incompatible types given to Integer.to_string/1:
Integer.to_string(:atom)
given types:
-:atom-
but expected one of:
integer()
└─ a1_r3.ex:8:29: A1R3.f/0
current main / v1.20 RC (b58e84352):
warning: incompatible types given to String.length/1:
String.length(1)
given types:
-integer()-
but expected one of:
binary()
└─ a1_r3.ex:6:35: A1R3.f/0
4. else body warning before rescue body:
defmodule A1R4 do
def f(x) do
try do
x
rescue
_ in RuntimeError -> Integer.to_string(:atom)
else
:ok -> String.length(1)
end
end
end
v1.19.5 (d33fd8e41):
warning: incompatible types given to Integer.to_string/1:
Integer.to_string(:atom)
given types:
-:atom-
but expected one of:
integer()
└─ a1_r4.ex:6:36: A1R4.f/1
current main / v1.20 RC (b58e84352):
warning: incompatible types given to String.length/1:
String.length(1)
given types:
-integer()-
but expected one of:
binary()
└─ a1_r4.ex:8:21: A1R4.f/1
Concern
So, try seems to suppress diagnostics after the 1st failing alternative. Equivalent non-try structures still behave as expected (case clauses, multiple catch clauses, or multiple else clauses); they report independent clause warnings.
Investigation
The behaviour appears to come from lib/elixir/lib/module/types/expr.ex:
tryhandleselsefirst, then reducesrescue/catchblocks sequentially;- Rescue clauses are checked by an inline nested
Enum.reduce; of_rescue/9resets variables after the rescue body withOf.reset_vars/2, but it does not isolate or restorefailed;- Normal clause checking goes through
of_clauses_fun/7, which wraps each clause withreset_failed/2andset_failed/2, allowing independent diagnostics while preserving the final failed state.
0
josevalim
Creator of Elixir
Others have already explained that both short-circuit but I want to add that said warning is not coming from Elixir. 
0
sodapopcan
Oh for sure, I’ve just always found it odd is all I’m saying. Like it would be nice to know that and and or always return a boolean. My comments around the warning are akin to 1 > :foo being totally legal and documented but now being flagged as a warning (which is nice). Although there are probably good scenarios where you would want bool on the left and get get the return value of the right, I just can’t think of any of the top of my head.
Also, confusion is also because I missed this post of yours due to the way the Discourse notifications work and you replied directly too me after that one.
0