<p dir="ltr">As for including guards, it is not possible to warn about all cases where a clause cannot be matched.</p>
<p dir="ltr">Consider:<br>
f (X, Y, Z) when X*X*X+Y*Y*Y==Z*Z*Z, is_integer(X), is_integer(Y), is_integer(Z), X>0, Y>0, Z>0 -><br>
... you get the picture. :)</p>
<p dir="ltr">Linear patterns would be doable.<br>
Non-linear patterns perhaps too, but probably less straightforward.</p>
<div class="gmail_quote">Den 03/03/2014 18.16 skrev "Vlad Dumitrescu" <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>>:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 3, 2014 at 5:49 PM, Björn Gustavsson <span dir="ltr"><<a href="mailto:bjorn@erlang.org" target="_blank">bjorn@erlang.org</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>> On Fri, Feb 28, 2014 at 7:54 PM, tom kelly <<a href="mailto:ttom.kelly@gmail.com" target="_blank">ttom.kelly@gmail.com</a>> wrote:<br>



>><br>
>> -module(no_warn).<br>
>> -compile(export_all).<br>
>><br>
>> -record(my_rec,{field1, field2}).<br>
>><br>
>> my_function1(#my_rec{field1 = {tag, _}, field2 = f2}) -> 1;<br>
>> my_function1(#my_rec{field1 = {tag, 1}, field2 = f2}) -> 2; % line 7<br>
>> my_function1(_) -> 3.<br>
>><br>
>> my_function2(#my_rec{field1 = {tag, _}}) -> 1;<br>
>> my_function2(#my_rec{field1 = {tag, 1}}) -> 2; % line11<br>
>> my_function2(_) -> 3.<br><br>
</div></div>It is perhaps a documentation bug.<br>
<br>
Some warnings can be trusted 100 per cent.<br>
For example, if there are no warnigs for unused variables<br>
there are no unused variables.<br>
<br>
The absence of warnings for clauses that<br>
don't match does *not* mean that that all clauses<br>
can be matched. It merely means that<br>
the compiler (during optimisation and<br>
pattern matching compilation) did not find<br>
any clauses that obviously would not be<br>
reached.<br>
<br></blockquote><div> </div><div>Hi,</div><div><br></div><div>I'm not sure if I can agree with this. Non-matchable clauses should in my opinion be marked as errors, because they expose a logical flaw (usually a misordering of the clauses), and in this case I would have them be 100% accurate.</div>


<div><br></div><div>Given clauses without guards like f(A)->ok; f(B)->ok. then I think we should get a warning/error if B is the same as or more specific than A. This probably applies when there are guards too. If that's the case, it shouldn't be too difficult to implement.</div>


<div><br></div><div>What am I missing? Is it difficult just because it is done after some optimization passes that might mess things up? Or is there some other issue?</div><div><br></div><div>best regards,</div><div>Vlad</div>


<div><br></div></div></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div>