I’ve been in need for an ets:select_take function. Currently a select of all keys for matching elements followed by a take is required since select_delete returns only the number of deleted elements. Could also do a select/match followed by a delete but that would mean some updates would technically succeed on an element but not be part of what was selected.
Curious if anyone else has encountered need for this and if anyone knows what an implementation would look like.
I only glanced at some of code on my phone, and I might firing off too quick here… but you could either set up the implementation of select_delete to accumulate the terms that are simply freed in the current implementation (i.e., have an accumulator in the state that is either Uint or an Eterm based on an extra argument passed in), or copy / pasta and modify 
I think this would be a nice thing to have. I want to say I needed something like this in a previous project, but I’d have to go back and look at what I was doing (some type of queue iirc).
I wish there was just 1 forum for BEAM :). Wondering if I should cross-post this to Elixir forum to see if others also think it is useful.
You probably should, there seems to be a summer lull here
As for a single forum, it’s an interesting thought, maybe another conversation should be spun up around it?
Oh right… Europeans.
I guess I’ll still crosspost and if it gets any traction over there I can use it as ammo for why we should consolidate
It’s been a minute, It seems like @sverker would be the person to ping here as to whether there is any gotchas with an select_take implementation.
Maybe a more generic solution could be to extend the match spec for select with a {delete} action.
ets:select(Tab, [{{'$1',0}, [], [{delete},'$1']}]).
would then delete all {_,0} tuples and return the keys only.
A little more cryptic than a select_take but more versatile. It would also break the current “rule” that ETS match spec bodies do not have side effects.
Or maybe not an extension of the current ets:select which now is a pure read-only operation.
Just thinking out loud…
That’s interesting! Maybe a select_take fun could be added on to ets that just inserts that flag? Whatever results in less C code IMHO 
@tsloughter Also had the idea of select_replace , which is on topic for this thread I believe.
I realized in my case I actually could just do select of all the keys I want and then a take on the list of keys and maintain the properties I need :). Any writes to new keys that would otherwise be part of the take but are between the select and take would be part of the next collection, nothing lost.
I still think a select_take would be useful instead of having to do two steps, but its not a big deal since this is on a slow path.
I think I’m more interested in a select_replace that can return results. I’m trying to dig up again where that would make my life easier before opening an issue on the OTP repo. And I’ll still include select_take in that issue.
Oopts, take/2 doesn’t take a list of keys…