Stream: show and tell

Topic: niclas-ahden/roc-non-zero

Niclas Ahden (Aug 02 2026 at 22:43):

Got a function that wants a non-zero number? https://github.com/niclas-ahden/roc-non-zero

Aurélien Geron (Aug 02 2026 at 22:50):

Nice and simple, I like it! The compile-time examples are pretty slick.

Note: in your README.md, you have this section:

app [main!] {
    pf: platform "https://github.com/niclas-ahden/basic-cli/releases/download/0.23.0/7NpDhuqoqGFedmVLvmm1zjq37GCmaFGzwr5sz4ch9wTK.tar.zst",
    nz: "../package/main.roc",
}

If people want to try out this example, they need to replace "../package/main.roc" with a recent release URL. It would be nice to replace this with the actual release URL, to remove this little friction.

Niclas Ahden (Aug 02 2026 at 23:00):

Thanks! I generally update the readme when the release finishes building, and it just wasn’t done yet :) Perhaps I should make a habit of putting the release url in there before pushing even!

Richard Feldman (Aug 03 2026 at 01:02):

this is interesting! I was debating whether we should have these in the stdlib like Rust does - an advantage of having them as builtins is that there are some compiler optimizations that can happen (e.g. omitting division-by-zero checks) but I wasn't sure if it was worth it :smile:

Niclas Ahden (Aug 03 2026 at 09:42):

@Richard Feldman Would it be possible to make the built-in even more ergonomic as well?

Roc's Json.parse, string pattern matching, and compile-time evaluation (e.g. div by zero) are features that make my eyes light up and I think newcomers will feel the same. Perhaps non-zero number handling could be another case where some compiler magic makes it crazily nice?

Richard Feldman (Aug 03 2026 at 14:28):

I think pattern matching and comptime eval should already work with your third party package

Richard Feldman (Aug 03 2026 at 14:29):

I haven't thought about parsing but there's likely a way to get that to work too, although for it to be as efficient as possible, the encoding needs to know the number type in question exists - which would be an argument for having it be a builtin

Richard Feldman (Aug 03 2026 at 14:33):

there's also a related argument for nonempty lists, and giving lists the same from_numeral / from_quote treatment that numbers and lists have

Niclas Ahden (Aug 03 2026 at 14:35):

Yeah, and what if you could do it to strings too?

Built-in or package doesn't matter to me at all. I just want the best ergonomics and performance which sounds like it may come from a built-in! One for Roc and Roc for all! :tada:

Richard Feldman (Aug 03 2026 at 14:57):

Niclas Ahden said:

Yeah, and what if you could do it to strings too?

what did you have in mind regarding strings?

Niclas Ahden (Aug 03 2026 at 15:10):

I was thinking we may have a nice way to express/guarantee that a string is non-empty (besides just wrapping it in a type, like we can today). Not dependent types, but more along the lines of these compile-time checks and how they can be used. Perhaps I should write some more code and experiment to get to a concrete suggestion instead of being vague :P

Richard Feldman (Aug 03 2026 at 16:08):

cool, that sounds good! :smiley:

Richard Feldman (Aug 03 2026 at 16:08):

kinda interesting to imagine a family of these, like U64.NonZero, List.NonEmpty, Str.NonEmpty

Richard Feldman (Aug 03 2026 at 16:28):

this would be pretty cool :sunglasses:

len : List.NonEmpty(_item) -> U64.NonZero

Last updated: Aug 12 2026 at 12:35 UTC