I wonder if maybe a Credo check might be better suited for this rather than a built-in compiler warning.

That said, another thing that we could improve in the language (or rather in ExUnit), is the test feedback when assertions on builtin guards are used, e.g. for `assert is_map(foo)` we could show "Expected a map, got foo" rather than "Expected truthy, got false".

~Marten/Qqwy

On 22-10-2021 15:14, Łukasz Niemier wrote:
In any case, my recommendation is to always do `assert actual == expected` and 
`assert expected = actual`, never `assert expected == actual`. And yeah, I 
think you're making a good point about matching on map is definitely a possible 
foot gun, but I personally don't think it should be enforced by the tooling.
I do not fact that the order of the expected and actual value depends on the used operator. I 
always use `assert <expected> <op> <actual>` to have some uniformity.

However even if someone uses them in the way you pointed there, there are 
examples where it failed in the wild [1]. While I can support fact that 
language should not force particular style of writing code (which is funny 
thing to say as `Code.format_string/{1,2}` is built in), we should help users 
with informing them that they used potentially problematic form (just as we do 
with `foo` vs `foo()`).

[1]: https://github.com/phoenixframework/phoenix/pull/4559/files

--

Łukasz Niemier
[email protected]


--
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/01f68cb8-d87c-ffb1-71b5-95105ef468dc%40resilia.nl.

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to