Summary

After talking with many folks I have come to understand that as long as 1 path in my code leads to a successful execution that is compatible with the specs I provide, dialyzer will not complain.

There may be many paths that break, but as long as 1 works, dialzyer is happy.

In my specific case, because I have a branch that returns [{:some, String.t}] dialyzer does not complain, because I have 1 branch that succeeds.

This can be better summarized in the quote from Type Specifications and Eralng:

The other option is then to have a type system that will not prove the absence of errors, but will do a best effort at detecting whatever it can. You can make such detection really good, but it will never be perfect. It’s a tradeoff to be made.

In fact, the article mentioned above, has an example case very similar to my own:

main() ->
    X = case fetch() of
        1 -> some_atom;
        2 -> 3.14
    end,
    convert(X).

convert(X) when is_atom(X) -> {atom, X}.

Which also does not trigger dialyzer. According to the article:

From our point of view, it appears that at some point in time, the call to convert/1 will fail.
(…)
Dialyzer doesn’t think so. (…) because there is the possibility that the function call to convert/1 succeeds at some point, Dialyzer will keep silent. No type error is reported in this case.

This is quite enlightening and I am convinced this is what is happening in my case.

Will dialyzer ever understand what is going on?

To be fair, this error can be caught by dialyzer if we use some flags, namelly --overspecs (for this case) and its sister --underspecs (which we don’t need for this case).

After some research I was able to find a mailing list that details the behaviour of these flags in a mathematical format:

• [erlang-questions] Dialyzer underspecs and overspecs options

From it:

Let SpecIn be a set of @spec inputs and RealIn be a set of inputs as inferred by Dialyzer from real code, then:

• The Input Contract is satisfied when SpecIn <= RealIn (where <= is a non-strict subset operation). See over_in in demo code below.
• The Input Contract violation is detected by -Wunderspecs option when SpecIn > RealIn. See under_in below.

It is easy to see in the code:

• It’s OK for over_in to declare that it only accepts :a and :b while it also happens to accept :c. Maybe suboptimal, but fine.
• It’s NOT OK for under_in to claim that it accepts :a, :b and :c and break if :c is passed. Rejecting :c would break the caller.

Let SpecOut be a set of @spec outputs and RealOut be a set of outputs as inferred by Dialyzer from real code, then:

• The Output Contract is satisfied when SpecOut >= RealOut (where >= is a non-strict superset operation). See under_out below.
• The Output Contract violation is detected by -Woverspecs option when SpecOut < RealOut. See over_out below.

It is easy to see in the code:

• It’s OK for under_out to declare that it returns :a, :b and :c, while currently it only returns :a and :b. Maybe future implementations will return :c as well.
• It’s NOT OK for over_out to declare that it returns :a and :b, but to also return :c sometimes. Returning :c would break the caller.

And indeed if I run mix dialyzer --overspecs with this sample, dialzyer does complain becasue:

The Output Contract violation is detected by -Woverspecs option when SpecOut < RealOut. See over_out below.

Where RealOut is [] | [t] | nil and SpecOut is [] | [t].
Therefore, a contract violation is detected.

Error shown:

lib/test.ex:6:missing_range
The type specification is missing types returned by function.

Function:
Test.validate_name/1

Type specification return types:
[{:some, binary()}]

Missing from spec:
nil

This was a wild ride through Dialyzer, and a revision I quite honestly needed. During the whole ordeal I learned about a couple of dialyzer flags and I refreshed my memory on success typing (which I absolutely needed to).

Thank you everyone for participating !

Quite interesting. I’m definitely going to use the --overspecs flag then because (a) it is more strict and (b) seems to give more readable error messages.

Thanks for sharing!

You can try reversing the conditional and you’ll see it’s not about happy path or not (how would dialyzer even know what a happy path is). Dialyzer only takes issue if it there is no way your function will ever work.

For your validate_name/1 there’s plenty of inputs, which are ok. Basically anything, which is not "" will produce a return value aligning with your typespec. If you remove the conditional and return nil for every case and suddenly dialyzer is no longer as happy. It detected that the only possible return is nil, which doesn’t align with your typespec.

You can dig deeper by adding another function to your module:

  @spec test :: nothing
  def test do
    validate_name("")
  end

This one dialyzer will complain about.

lib/test_dialyzer.ex:34:invalid_contract
The @spec for the function does not match the success typing of the function.

Function:
Test.test/0

Success typing:
@spec test() :: [{:some, binary()}, ...]

As you can see dialyzer never considered the nothing branch of your union a return value of validate_name.

To my knowledge this is because dialyzer inferred validate_name to return nil | [{:some, binary}, ...], but the typespec tells it that it should be [] | [{:some, binary}, ...]. The overlap between both is just [{:some, binary}, ...]. That’s enough for dialyzer to be fine in regards to validate_name/1. Adding test/0 however adds a function, where the typespec and the success typeing have no possible overlap anymore. Therefore you get an error.

The thing to understand here is that success typing is not all all concerned with exhaustive checks (at least with the default flags). It doesn’t care if your typespec has parts, which are off, for as long as there’s some “correct” parts to it. Correct meaning matching to the inferred type of dialyzer. So thinking your typespec is a 100% match just because dialyzer doesn’t complain is an incorrect expectation.

You can make dialyzer catch the issue by enabling the :underspecs (there’s also :overspecs) flag. This will make dialyzer complain if parts of its inferred type is not covered by the typespec in code.