See https://github.com/roc-lang/roc/issues/9596
It's come up a few times, so I thought I'd ask our LLM friends to sift through all the details I could find and put together a consolidated list of missing builtins for us to coordinate around.
I've locked and pinned the issue so we can limit discussion to Zulip ideas threads or more specific GH Issues.
It would be helpful if you see anything that doesn't look right to let me know... I've tried to compile a lot of detail and almost certainly missed some things
I've made a start on two of these
(1) https://github.com/roc-lang/roc/pull/9599 -- implement Dict with an insertion-ordered hash map
(2) https://github.com/roc-lang/roc/pull/9600 -- all of the remaining Numeric builtins
Shouldn't all the builtins that were suffixed with _checked in the old compiler use _try instead, to be consistent with the change in naming of the to_ conversion functions?
that makes sense to me
I just updated the tracking GH Issue for the remaining builtins -- https://github.com/roc-lang/roc/issues/9596
These are the things remaining from what I can see
Dec conversionsStr and List helpersSet helpersI mistook the log API for a logging API, which I haven't seen discussed much. Is that on the radar?
log or logging?
Logging API -- that sounds like an effect that a platform would provide and be responsible for
There isn't anything in the design for the Roc<->Host ABI (unlike dbg, crash, allocations etc) so I do not think there is any plan to add that.
Logging specifically. Might be nice to do something similar to HTTP, where we have built-ins for "constructing" the log and you can then choose to log using dbg or have the host expose a function to write a logging file for instance.
I'm not tracking anything, would you like to start an #**ideas thread about it?
I see List.map! has been deferred. I was just needing to map over some things using a db connection. I know I can use for loops (and preallocated destination) but was curious as to why it's been pushed back?
the only reason was just "is there a real use case for this or are we only including it because it's obvious how it would work?"
if you've found a real use case, happy to add it! :smile:
I'm just curious what the use case turned out to be haha
Just a minor convenience. Wanted to fetch some data for a list of ids: jobs = ids.map!(|id| Query.get_job_data(q, stmt, id)) (I know, not using a batched query)
You might say that not adding it here is good to discourage N+1 -- fair enough :laughing:
Would it be possible to add List.for_each_try! : List(a), (a => Try({}, err)) => Try({}, err) aswell?
Also just minor convenience, so I can refactor this:
main! = |_args| {
for line in Stdin.lines!()? {
Stdout.write!("${line}\n")
}
Ok({})
}
seems reasonable! :+1:
Effectful pure-ish functions like List.map! are also nice for platform-specific pure-ish functions like floating point SIMD.
oh we're going to add floating point SIMD, just haven't gotten to it yet. Is that blocking you?
Not blocking! I'm not deep in yet.
I could see other platforms having their own pure-ish things that would be out-of-scope though. That sort of platform-provided custom data transformation just another category that would use a List.map!
A message was moved from this topic to #ideas > `List.has_any_match` and `List.for_each_try` by Luke Boswell.
Last updated: Sep 24 2026 at 15:59 UTC