Attempt at improving "colored functions" in Rust

I've just published a first version of my package desaturate. One of the main complaints I hear about Rust is the "colored functions", so the goal of this library is to enable smaller library developers to provide both blocking and async versions of a function, with minimal code duplication and minimal dead code in the compiled binaries. Pretty much everything is a first draft, but I would love some feedback on it.

If you're a library developer I would also really like to know if this looks like something you would like to use yourself, to get an understanding of whether this project is worth pursuing.

I have some cleaning up to do, mainly in transformers.rs, but I wanted to throw it out here before I put more work into this.

5 Likes

Colored functions are not specific to Rust and the concept has largely been retired as far as I know.

It is still an open issue for Rust at least in the sense that the keyword generics project is not closed. My understanding (just based on reading a few comments) is that the project is very controversial and perhaps won't happen, but there is no way to say for certain at this early stage.

1 Like

A couple of recent and popular things related to coloring:

  1. Let futures be futures
  2. https://www.youtube.com/watch?v=MTnIexTt9Dk&list=PL85XCvVPmGQgR1aCC-b0xx7sidGfopjCj
1 Like

I think keyword generics are now called an effect system and at least Yosh Wuyts seems to be excited about it :slightly_smiling_face:

1 Like

The article by boats does mention that the removal of libgreen and related has been closed as complete.

You seem to have linked some really interesting stuff, which I will take a look at. For now, though, this experiment feels like a failed one. It’s really not as ergonomic as I envisioned, and it completely breaks LSP, which is a complete dealbreaker for usability. Even ignoring LSP, the types is a huge problem. Blocking and async types differ, so we would need to be able to use different arguments for blocking and async functions, which would require some bad voodoo. The function would have to be really bad, like fn job<const ASYNC: bool, T: MaybeAsync<ASYNC>>(args: F::Args) -> F::Output (and a lot of magic to somehow get that to a compiling state), with every function call to a function which has different types for blocking and async code explicitly using ASYNC in every function call.

It was an interesting project, but I feel fairly certain that its reached it’s conclusion.