What's the point if it's incompatible? The README suggests using go's testing toolchain and type checker, but that's unreliable if the compiled code has different behavior than the tested code. That's like testing and typechecking your code in a C++ compiler but then for production you run it through a C compiler.

Would have been a lot more useful if it tried to match the Go behavior and threw a compiler error if it couldn't, e.g. when you defer in a loop.

Is this just for people who prefer Go syntax over C syntax?

As long as you exclude defers in a loop, this can be done statically: count the maximum number of defers in a function, and add an array of that size + counter at the function entrance. That would make it a strict subset.

tbh I'd rather have this behaviour, defer should've been lexically scoped from the beginning.

> This means that the number of actively-deferred statements is unbounded, which implies heap allocation.

In C you can allocate dynamically on the stack using alloca or a VLA.