Hauleth's blog

Question

Q:</b> What will be result of Foo.a(%{foo: 21})</code>?</p>

true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> This one is straightforward.</p> We check guard, it has one condition is_integer(x) or is_map_key(x, :foo)</code>. First one returns false</code>, second returns true</code>, Boolean's alternative results in true</code> and first case is matched.</p> </div> </div> Q:</b> What will be result of Foo.a(37)</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> This one is straightforward as well.</p> We check guard, it has one condition is_integer(x) or is_map_key(x, :foo)</code>. First one returns true</code>, second one isn't fired at all, because or</code> operator is short circuiting.</p> </div> </div> Q:</b> What will be result of Foo.b(%{foo: 21})</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> Again, similar to the previous questions.</p> We check guard, it has one condition is_map_key(x, :foo) or is_integer(x)</code>. First one returns true</code> and the rest is short circuited.</p> </div> </div> Q:</b> What will be result of Foo.b(37)</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> Ouch, something changed…</p> Again, we check guard, one condition is_map_key(x, :foo) or is_integer(x)</code>. We hit the first clause is_map_key(x, :foo)</code> but this doesn't</strong> return false</code>, instead it fail. Failure in one of guard functions isn't converted to false</code> but instead makes whole guard expression fail. This mean that is_integer(x)</code> part will never</strong> be called.</p> </div> </div> This behaviour is often surprising for a lot of Elixir developers, as it seemingly breaks commutative property of boolean operators. However, to be honest, these never were commutative because of short circuiting.</p> It seems that Elixir at the time of writing (Elixir 1.20.1, OTP 29) do not warn about this issue.</p>

Answer 1

WRONG</div>

RIGHT</div>

This one is straightforward.</p>

We check guard, it has one condition is_integer(x) or is_map_key(x, :foo)</code>. First one returns false</code>, second returns true</code>, Boolean's alternative results in true</code> and first case is matched.</p> </div> </div>

Q:</b> What will be result of Foo.a(37)</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> This one is straightforward as well.</p> We check guard, it has one condition is_integer(x) or is_map_key(x, :foo)</code>. First one returns true</code>, second one isn't fired at all, because or</code> operator is short circuiting.</p> </div> </div> Q:</b> What will be result of Foo.b(%{foo: 21})</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> Again, similar to the previous questions.</p> We check guard, it has one condition is_map_key(x, :foo) or is_integer(x)</code>. First one returns true</code> and the rest is short circuited.</p> </div> </div> Q:</b> What will be result of Foo.b(37)</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> Ouch, something changed…</p> Again, we check guard, one condition is_map_key(x, :foo) or is_integer(x)</code>. We hit the first clause is_map_key(x, :foo)</code> but this doesn't</strong> return false</code>, instead it fail. Failure in one of guard functions isn't converted to false</code> but instead makes whole guard expression fail. This mean that is_integer(x)</code> part will never</strong> be called.</p> </div> </div> This behaviour is often surprising for a lot of Elixir developers, as it seemingly breaks commutative property of boolean operators. However, to be honest, these never were commutative because of short circuiting.</p> It seems that Elixir at the time of writing (Elixir 1.20.1, OTP 29) do not warn about this issue.</p>

Answer 2

WRONG</div>

RIGHT</div>

This one is straightforward as well.</p>

We check guard, it has one condition is_integer(x) or is_map_key(x, :foo)</code>. First one returns true</code>, second one isn't fired at all, because or</code> operator is short circuiting.</p> </div> </div>

Q:</b> What will be result of Foo.b(%{foo: 21})</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> Again, similar to the previous questions.</p> We check guard, it has one condition is_map_key(x, :foo) or is_integer(x)</code>. First one returns true</code> and the rest is short circuited.</p> </div> </div> Q:</b> What will be result of Foo.b(37)</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> Ouch, something changed…</p> Again, we check guard, one condition is_map_key(x, :foo) or is_integer(x)</code>. We hit the first clause is_map_key(x, :foo)</code> but this doesn't</strong> return false</code>, instead it fail. Failure in one of guard functions isn't converted to false</code> but instead makes whole guard expression fail. This mean that is_integer(x)</code> part will never</strong> be called.</p> </div> </div> This behaviour is often surprising for a lot of Elixir developers, as it seemingly breaks commutative property of boolean operators. However, to be honest, these never were commutative because of short circuiting.</p> It seems that Elixir at the time of writing (Elixir 1.20.1, OTP 29) do not warn about this issue.</p>

Answer 3

WRONG</div>

RIGHT</div>

Again, similar to the previous questions.</p>

We check guard, it has one condition is_map_key(x, :foo) or is_integer(x)</code>. First one returns true</code> and the rest is short circuited.</p> </div> </div>

Q:</b> What will be result of Foo.b(37)</code>?</p> true</code></label> </div> false</code></label> </div> WRONG</div> RIGHT</div> Ouch, something changed…</p> Again, we check guard, one condition is_map_key(x, :foo) or is_integer(x)</code>. We hit the first clause is_map_key(x, :foo)</code> but this doesn't</strong> return false</code>, instead it fail. Failure in one of guard functions isn't converted to false</code> but instead makes whole guard expression fail. This mean that is_integer(x)</code> part will never</strong> be called.</p> </div> </div> This behaviour is often surprising for a lot of Elixir developers, as it seemingly breaks commutative property of boolean operators. However, to be honest, these never were commutative because of short circuiting.</p> It seems that Elixir at the time of writing (Elixir 1.20.1, OTP 29) do not warn about this issue.</p>

Answer 4

WRONG</div>

RIGHT</div>

Ouch, something changed…</p>

Again, we check guard, one condition is_map_key(x, :foo) or is_integer(x)</code>. We hit the first clause is_map_key(x, :foo)</code> but this doesn't</strong> return false</code>, instead it fail. Failure in one of guard functions isn't converted to false</code> but instead makes whole guard expression fail. This mean that is_integer(x)</code> part will never</strong> be called.</p> </div> </div>

This behaviour is often surprising for a lot of Elixir developers, as it seemingly breaks commutative property of boolean operators. However, to be honest, these never were commutative because of short circuiting.</p> It seems that Elixir at the time of writing (Elixir 1.20.1, OTP 29) do not warn about this issue.</p>

Hauleth's blog

The Lion, The Witch, and the audacity of recruiters

Guards! Guards!

Reviewing code requires reading