fluid-macro 0.3.1

Write long method chains as a series of steps instead, and more!
Documentation
  • Coverage
  • 100%
    2 out of 2 items documented1 out of 1 items with examples
  • Size
  • Source code size: 7.51 kB This is the summed size of all the files inside the crates.io package for this release.
  • Documentation size: 1.08 MB This is the summed size of all files generated by rustdoc for all configured targets
  • Ø build duration
  • this release: 10s Average build duration of successful builds.
  • all releases: 10s Average build duration of successful builds in releases after 2024-10-23.
  • Links
  • Narvius/fluid-macro
    0 0 0
  • crates.io
  • Dependencies
  • Versions
  • Owners
  • Narvius

fluid-macros

A macro that allows you to write long method call chains as a series of steps instead, with support for sub-scopes.

Basic Usage

let x = fluid!("123", {
    parse::<i32>();
    unwrap_or_default();
    [- 100];
    [* 2];
    clamp(5, 100);
    to_string();
});

This is equivalent to writing:

let x = (("123".parse::<i32>().unwrap_or_default() - 100) * 2).clamp(5, 100).to_string();

(Motivating) Example

I was working on a little Visual Novel-like module for a game, with a DSL. I ended up creating a bunch of builders that modeled that DSL:

SceneBuilder::new().with_character(Cid::Player, |b| {
    b.message("Oh, what's this, a loose brick?")
        .choice("Should I push it?", |b| {
            b.branch("Yes", |b| { /* omitted */ })
                .branch("No", |b| { /* omitted */ })
        })
})

While the overall structure is fine, there's a lot of line noise--periods, |b|s, etc. Not to mention that the otherwise-lovely rustfmt really struggles with the nested builders. Thus I wrote this macro to be able to write this instead:

fluid!(SceneBuilder::new(), {
    with_character(Cid::Player) {
        message("Oh, what's this, a loose brick?");
        choice("Should I push it?") {
            branch("Yes") {
                /* omitted */
            }
            branch("No") {
                /* omitted */
            }
        }
    }
})

Known limitations

It's not very friendly to the IDE whilst writing. You will have to already know the names of methods you want to use. After compilation, however, symbol lookup and the like works fine.