<div dir="ltr">Further, the function find/2 is inconsistent with the style in the lists module. Other functions in the lists module returns 'false' instead of 'undefined' when an item not is found. See lists:keyfind/3 for example.<br>
<div><div><div><div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">/Håkan<br></div></div>
<br><div class="gmail_quote">On Mon, Oct 14, 2013 at 12:28 PM, Anthony Ramine <span dir="ltr"><<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello Sean,<br>
<br>
I don't like this patch.<br>
<br>
1/ You can't know whether an element was found or not if the list elements are arbitrary terms.<br>
2/ I don't see why you would say people hack either foreach/2 or foldl/3 to do that when they should just use dropwhile/2.<br>
<br>
A naive implementation of find/2 using dropwhile/2:<br>
<br>
find(F, L) -><br>
case dropwhile(fun (E) -> not F(E) end, L) of<br>
[] -> undefined;<br>
[E|_] -> E<br>
end.<br>
<br>
Regards,<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Anthony Ramine<br>
<br>
Le 14 oct. 2013 à 02:44, Sean Cribbs <<a href="mailto:sean@basho.com">sean@basho.com</a>> a écrit :<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> `lists:find/2,3` returns the first element of the passed list for which the predicate fun returns `true`. If no elements result in the predicate being true, `undefined` (/2) or the given default value (/3) is returned.<br>
><br>
> ## Why this new feature?<br>
><br>
> A common task is to select the first element from a list that matches a condition, but there is no existing lists function or language feature that avoids traversing the entire list, while still returning a "safe" value. `lists:find/2,3` codifies the pattern of a tail-recursive search for the matching item without resorting to exceptions (used to abort `foreach/2` or `foldl/3`) and always returns either the first matching item, or an otherwise safe value.<br>
><br>
> ## Risks / uncertain artifacts<br>
><br>
> It is unclear the desired order of arguments for the 3-arity version. I have made the default value the final argument which is consistent with `application:get_env/3` and `proplists:get_value/3`, but most functions in lists place the `List` argument last.<br>
><br>
> ## How did you solve it?<br>
><br>
> Following the patterns of other functions in the lists module, `lists:find/3` tests the predicate function against the head of the list, returning the head if the predicate passes, or recursing over the tail if it does not.<br>
><br>
> <a href="https://github.com/erlang/otp/pull/102" target="_blank">https://github.com/erlang/otp/pull/102</a><br>
><br>
> --<br>
> Sean Cribbs <<a href="mailto:sean@basho.com">sean@basho.com</a>><br>
> Software Engineer<br>
> Basho Technologies, Inc.<br>
> <a href="http://basho.com/" target="_blank">http://basho.com/</a><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> erlang-patches mailing list<br>
> <a href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
<br>
_______________________________________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
</div></div></blockquote></div><br></div></div></div></div></div></div>