I’d say the core issue here is having 2 completely different data structures - a map (set, ordered_set types) and a multimap (bag, duplicate_bag types) sharing the same access API. Whatever we do, there’s going to be confusion because of this “original sin” of ETS.
1 Like
Yes, but we can’t do anything about that now I guess 
All we can do now is not add more confusion (than necessary 
).
1 Like
I agree that always returning a list is cleaner.
What convinced me to switch to an extra argument to lookup_element is the precedent of maps:get and proplists:get_value.
But as a newcomer to Erlang, I’d be happy to implement whatever API the community prefer, whether that is lookup_element_as_list/3, lookup_element/4 or something else. All that I care about is that it be performant whether the element is present or not and reasonably ergonomic.
2 Likes
Personally I prefer the default.
The structure/type if the table and contents being interrogated is a known entity when you’re using it.
If it’s not, something is off 
If I know it’s a bag, I can always specify an empty list as the default.
I, as the programmer, get to make the decision in the actual call, rather than having to wrap it up in a case or function should I actually want to just use the returned value.
Just my 2c.
2 Likes
Actually, we don’t have to pick one or the other. @RMorisset could implement both, lookup_element/4 and lookup_element_as_list (but please, find another name ), if we ask him nicely 
2 Likes
The patch adding lookup_element/4 just landed (see Add lookup_element/4, which takes a default value by RobinMorisset · Pull Request #6234 · erlang/otp · GitHub), so it will be part of OTP 26. Thank you everyone for the comments and suggestions, and thanks Sverker for reviewing and landing my patch.
12 Likes