Hi Andrew- of course I've been following Zig. Thanks for your trailblazing efforts in the "C replacement" space.

It's true that symbols in 'false' preprocessor blocks will not be caught. Maybe it's best said "if the compiler will find the symbol when you compile, then the symbol renamer will find it when you rename". Which is definitely not true for most symbol renames I dare to attempt in C++ IDEs.

Damn, sorry, wasn't trying to call you out; rather hoping that you had thought of something I didn't that I could steal from you.

I think starting with an IDE from the very beginning was a smart move.

For what it's worth, here is my current vaporware plan to solve this problem: https://github.com/ziglang/zig/issues/3028

I would be curious to see your thoughts on this, especially if you end up trying to tackle this problem in Beef.

Ah- for BeefLang that's less of a problem since even unreachable code is typechecked (without code generation). But yeah your problem sounds very hard. I guess I don't fully understand why you would only want reachable functions to be listed in documentation...

I mostly wish that those refactor->rename features in my IDE also renamed code that is commented out.

Andrew, while you are here- can you please make smaller monthly zig releases instead of very large releases. 0.6 has been in the oven for a while now.

They do ~two annual releases. Composing a release is a major time-sink for a small project.

They probably want newcomers to try a release, and if intrigued, clone the repo and stay current.

I dont think a smaller release cycle should be a larger time sink, specially if the release process uses CI/CD which Zig does.

A shorter release cycle wil mean that folks will get new stuff/bugfixes faster and that Zig will get more mindshare in return.