Self Modifying Code as an alternative to macros (matklad.github.io)

The API in the article is try_from by another name... but leaving the question of panicking to the caller seems right to me. In the "I'm trying to respond to the error" case maybe unknown should be a panic, but what about when you share code with your log parser?

I think the difference is that the try_from implementation can’t be exhaustive because the input value space is much larger than the enum space, so nothing really requires you to add the new variant to that impl when you add the variant to the enum. This provides a non-macro solution that forces the two to stay in sync, which is pretty nice if you either don’t like macros or don’t feel comfortable building them yet. I agree with the author it’s also definitely more readable and obvious than a macro, even if the whole approach makes me feel a bit weird at first blush.

As you hint at in your last paragraph, it’s probably hard to come up with a blog-sized example for any programming technique. If 10-15 lines were really the extent our scope, we probably wouldn’t need anything more advanced than assembler. Some amount of imagination is necessary to consider whether an idea is useful in production code, so we all have different examples in mind.

Personally, I’ve had cases where three or four places had to be kept in sync, and the list was changing frequently enough that something like this became useful.

Even then, it’s still a judgement call whether code generation or (if available) macros are worth the complexity. The decision might also heavily depend on the experience of the team.

Iterating over an enum requires a macro (strum::EnumIter is a popular one), which you’d need in order to ensure the test code automatically covers all cases without needing updates. This does only work when your variants are non-data variants or data variants whose type implements Default, but it does allow you to force yourself to stay in sync.

Edit: you might could also do some shenanigans using integers, `as` conversions, and #[repr(u8)], but it seems like it would get nasty and potentially unsafe

    unsafe { transmute::<u32, Error>(error_code) }

Since the blog author is the primary developer of rust-analyzer, he must know about it. I think he might still have usability concerns about macros in rust IDEs.

I have been relying on cargo expand for macro debugging, let me check what utilities rust-analyzer has for this use case. Thanks for sharing.

EDIT: wow, it works exactly as you advertised, thanks a bunch again for sharing, such a nice productivity boost!

Thanks for the link, that seems very useful. I recently had to work around this by transforming a list (a, b, c, d) into something like 1+1+1+1+0 to get a count. What this RFC proposes looks so much less painful.

  macro_rules! count {
      () => (0);
      ($odd:tt ($a:tt $b:tt)*) => ((count!($($a)*) << 1) | 1);
      (($a:tt $b:tt)*) => (count!($($a)*) << 1);
  }

Just to be sure: goto is perfectly fine for error handling in C.

I think that mixins - both template mixins that essentially copy/paste declarations (including functions) and the mixin statement that takes a string to be compiled as source code - can be as weird to follow as macros in C.

Contrived example:

    import std.stdio;
    mixin template Func(string s, string r)
    {
        mixin("string " ~ s ~ "()" ~
        "{" ~
            "return \"" ~ r ~ "\";" ~
        "}");
    }
    mixin template Comb(string name, char c=',')
    {
        mixin(function string(){
            import std.conv;
            string r;
            enum counter(size_t x=[__traits(allMembers, mixin(__MODULE__))].length)=x;
            string suffix = to!string(counter!());
            r ~= "mixin Func!(\"Foo" ~ suffix ~ "\", \"Hello\");";
            r ~= "mixin Func!(\"Bar" ~ suffix ~ "\", \"World\");";
            r ~= "string " ~ name ~ "() {";
            r ~= "return Foo" ~ suffix ~ "() ~ \"" ~ c ~ " \" ~ Bar" ~ suffix ~ "();";
            r ~= "}";
            return r;
        }());
    }
    void main()
    {
        mixin Comb!("Mixer");
        writeln(Mixer());
    }

It is just that the language has more features than C so they aren't needed as often. But in my eyes at least the mixin statement is basically C macros on steroids :-P.

> However, some colleagues have the opinion that those conflicts are trivially resolved by rebuilding and thus don’t matter

This is how mistakes happen, and when dealing with things like serialisation is an absolute _minefield_

> nd having diffs of the generated code show up in pull requests adds value.

They do have a point here, but is there a reason that the generated code diff couldn't be done separately to being commited?

> What do others think, check in generated code or put it in gitignore?

Always ignored, no questions asked. Generated code is a build artifact, the same way an object file or a jar is. It just happens to be human readable.

Your build system should be 100% bulletproof and pick up changes to your input files and correctly regenerate the output files for you, anything less should be considered a p0 bugfix. If you need to cache these files for whatever reason, do so at a different level (sccache/container/whatever).

If you're going to check it in, at least have a CI job which rebuilds it from scratch, then fails if there are any changes.

I'm not persuaded of the value of having diffs in source control, but i haven't looked at concrete examples. This would be an interesting post for someone to write.

For performance, i'd rather follow a distributed caching approach. Hash the true source, look for /some/nfs/mount/or/s3/path/${hash}.tar.gz, if it exists, unpack it into the generated source directory, if not, generate the source, tarball it, and upload that to the said path. Takes some care to hash the right things (needs to include the version and configuration of the generation tool, etc). Again, you could have a CI job checking that the caches are correct if you're worried.

I like checking it in; on balance, I think it makes life nicer:

Simpler to get started running the code, less compute wasted running generators (this is especially nice when doing something like bisect), and it's nice to be able to just see all your code, right there in the repo.

I actually think the biggest downside is the diffs -- often there's no easy way (e.g. in GitHub) to hide all generated code, which can be annoying.

Merge conflicts don't bother me at all, since they're so easy to resolve; I agree with your colleagues there.

(Though that would be trickier if you had files mixing generated and hand-written code! Contra the original article, my instincts/advice would be to always keep generated code well-isolated from hand written code, ideally using some standard convention [e.g., all generated stuff is in /generated/ path].)

It’s not that simple. Also, the article isn’t about binaries at all, but about code generation at build time.

> virus checker

That industry is founded purely on fear and very little actual expertise. They should not fulfill an example role in your mind and nobody should actively listen to them when considering the future.