Stream: ideas

Topic: Roc version and package version in program output


view this post on Zulip Aurélien Geron (Aug 30 2026 at 03:07):

It's sometimes useful to programmatically access the compiler version in your code, for example to print it out, or to possibly behave differently depending on the version (e.g., if an algorithm is faster with a given version than with another), or when you can run Roc code but not commands (e.g., in Exercism exercises, or when writing plugins).

I propose to add System.roc_version() to the stdlib. It should probably return a Version type. In fact, having a Version type in the stdlib might be useful in and of itself.

It might also be a good idea to also make the platform version and package versions available too. For example System.platform_version() and unicode.package_version().

view this post on Zulip Richard Feldman (Aug 30 2026 at 03:50):

I get nervous about things like this...having code that behaves differently based on conditionally looking at the compiler version can introduce a whole new class of problems (e.g. "I upgraded to a patch release and things are suddenly behaving differently") and I would not want to open the door to that lightly :sweat_smile:

view this post on Zulip Richard Feldman (Aug 30 2026 at 03:50):

how would this be used in ecercism?

view this post on Zulip Aurélien Geron (Aug 30 2026 at 03:54):

I see your point. I guess it makes more sense for a dynamic language.
In Exercism, I'm never sure exactly which version is currently in production because it seems to take a little while for the latest roc-test-runner to actually be deployed. Since I can't run roc version, I can only tweak Roc code, I was hoping to add dbg System.version() or something. That said, I could update the roc-test-runner to display the version when tests fail. No biggy.

view this post on Zulip Richard Feldman (Aug 30 2026 at 04:34):

nice, that sounds like a good solution! :smiley:


Last updated: Sep 03 2026 at 15:16 UTC