[erlang-questions] Dyalizer warnings for too wide return type

[Vincent de Phily]

On Tuesday 12 October 2010 08:48:57 Alexey Romanov wrote:
> One problem I have with Dialyzer is that it complains about cases
> where the return type specified is too wide.
> 
> E.g.
> 
> -type handle_cast_return() :: {noreply, tuple()} | {noreply, tuple(),
> integer()} | {stop, any(), tuple()}.
> -spec handle_cast(any(), tuple()) -> handle_cast_return().
> handle_cast(_Msg, State) ->
>     {noreply, State}.
> 
> The definition says that handle_cast returns what it is supposed to
> return according to behaviour, but it gives this warning:
[...]
> the given specification satisfies it, and shouldn't result in a
> warning. Or at least, there should be an option to turn this set of
> warnings off, and I don't see one in
> `dialyzer -Whelp`.

It sounds like -Wunderspecs or -Woverspecs would do that, but that doesn't 
seem to work. Actually it looks like (contrary to documentation) -Wunderspecs 
is on by default and we actually need a -Wno_underspecs option.

But a global no_underspec for the program sounds dangerous too (you'll hide 
actual underspecs which should be fixed). Maybe dialyzer could ease the pain 
by handly behaviour spec specially ?

> -spec some_test() -> boolean().
> some_test() -> false. %% TODO implement later
> 
> %% in a different module
> foo() ->
>   case m1:some_test() of
>     true -> ...
>     false -> ...
>   end.
> 
> In addition to the warning about some_test() I get warnings about
> foo(): "Pattern 'true' can never match type 'false' ", any functions
> called only from the 'true' branch are reported to be unused, etc.
> While these warnings are correct, they ignore my specification for
> some_test(). Can Dialyzer be forced to prefer the return type given in
> the spec over the` one it infers?

Yes, that annoys me as well. I understand the warning for the some_spec 
function, but I think it shouldn't trickle down to the foo function. I have 
another use-case where I recompile a module at runtime but provide an initial 
implementation that always returns false.

I'd like dializer to trust me when I declare my interface, even if the 
implementation doesn't match that. Actually, maybe we could make the case that 
non-exported functions must have an exact spec whereas exported function can 
have a spec that is more allowing than the implementation ?

-- 
Vincent de Phily
Mobile Devices
+33 (0) 142 119 325
+353 (0) 85 710 6320 

Warning
This message (and any associated files) is intended only for the use of its
intended recipient and may contain information that is confidential, subject
to copyright or constitutes a trade secret. If you are not the intended
recipient you are hereby notified that any dissemination, copying or
distribution of this message, or files associated with this message, is
strictly prohibited. If you have received this message in error, please
notify us immediately by replying to the message and deleting it from your
computer. Any views or opinions presented are solely those of the author
vincent.dephily@REDACTED and do not necessarily represent those of 
the
company. Although the company has taken reasonable precautions to ensure no
viruses are present in this email, the company cannot accept responsibility
for any loss or damage arising from the use of this email or attachments.