Hi! I have that idea for some time now, unrelated to roc initially: pure functional programming, but with explicit opt-in move semantics. This would allow users to enforce the optimization of reference count optimizations. Is it something that exists right now in roc, or might be interesting? Or would it be too much of a low level construct?
As a user, it would allow me to write high level code without worrying that an operation somewhere accidentally prevents the compiler from performing in-place mutation. Maybe, by attaching an Attribute on a parameter? Like annotating a parameter with [reuse]
or whatever
So the goal would be a compilation failure if the parameters ever had more than one reference?
So really it is more trying to ensure uniqueness of a value so it can be mutated in place, rather than move semantics?
Yes, it would give me the guarantee that performance optimization is done as I intended.
In any case, users will always strive to architect their code in a way that allows for optimizations in hot paths. Instead of adding a comment saying "should be optimized during compilation", one could add a simple attribute that reports me an error if the optimization cannot be done. This would allow fearless refactoring of hot paths
Interesting feature :)
There is talk of adding a keyword that will check at runtime if a value can be modified in-place and fail test (or log a warning) if the check fails
Folkert implemented uniqueness types in the language a few years ago, but they were removed because they were deemed to be a net negative for the language and ref counting/opportunistic in place mutation was found to be ergonomic (by my understanding)
Interesting. How exactly was it implemented? As a type? Maybe all it needed was a special syntax? Why was it deemed negative, considering it was opt-in?
Last updated: Jul 06 2025 at 12:14 UTC