<div dir="ltr">Yes, I was thinking about separate functions, like mapfind, mapmerge etc, not about making a Frankenstein from lists:key** ones. Of course there's no problem to write such simple library myself, but having built-in fast bifs would be just more convenient as the more and more people will model objects by maps instead of proplists, use lists of such objects in their programs and expect CRUD operations over such lists.<div><div><br></div><div>There are 12 lists:key*** functions at the moment and it looks like it makes sense to replicate all of them as lists:map*** ones. The edge error cases will be "what to do when a map does not contain the key?". In this case lists:key*** behave differently in different functions - lists:keymap throws and exception when list contains a single non-tuple, lists:keydelete allows such lists. <br></div></div><a name="keymap-3"></a></div><div class="gmail_extra"><br><div class="gmail_quote">2014-11-23 17:43 GMT+03:00 Lukas Larsson <span dir="ltr"><<a href="mailto:lukas@erlang.org" target="_blank">lukas@erlang.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I agree with you that in certain situations they would be very convenient. I've myself already written these functions in a couple of modules.</div><div><br></div><div>How do you imagine the semantics would work? It is fairly straight forward when the list only contains maps or tuples.</div><div><br></div><div>lists:keyfind(you, name, [#{ name => me, from => here }, #{ name => you, from => there}]) returns #{ name => you, from => there}.</div><div><br></div><div>But if we start to mix them some interesting corner cases pop up:</div><div><br></div><div>lists:keyfind(2, 1,[#{ 2 => 3 },{2, 4},#{ 1 => 2 } ]) returns {2,4} or #{ 1 => 2 }?</div><div>lists:keyfind(1, id, [{1,2}, #{ id => 2}, #{ id => 1}) returns #{ id => 1 } or crashes as id is not a valid key for {1,2}?</div><div><br></div><div>Or error cases of today:</div><div><br></div><div>lists:keyfind(2, id, []) today gives badarg, but should return false for a map list?</div><div><br></div><div>The safest way to introduce these functions would be to create new ones called something like lists:mkeyfind, but if possible it would be very neat to use the same API. It really is unfortunate that lists:keyfind is so forgiving today, you can mix and match whatever you want in the list and keyfind will quietly ignore it.</div><div><br></div><div>Also we have to consider which of the lists:key* functions we want a map counterpart? Does it make sense for all of them?</div><div><br></div><div>Thoughts? Ideas? Suggestions?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Lukas</div><div><br></div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Nov 22, 2014 at 7:33 PM, John Doe <span dir="ltr"><<a href="mailto:donpedrothird@gmail.com" target="_blank">donpedrothird@gmail.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><div dir="ltr">It would be nice to extend lists module with a set of optimized functions like lists:key*** for lists containing maps. </div>
<br></span><span class="">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">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></span></blockquote></div><br></div>
</blockquote></div><br></div>