Without one, you couldn't 'defer' to the end of a containing block from within an if/while/do/for/etc. block.
When/where the deferred code is executed has to be specified some way so an explicit marker for the defer 'scope' is surely required without severely limiting the utility of the feature.
guard {
void *ptr = malloc(12);
if (ptr) {
defer free(ptr);
// Use ptr
}
// Use ptr some more
} // free ptr here
{
void *ptr = malloc(12);
defer { if (ptr) free(ptr); }
if (ptr) {
// Use ptr
}
// Use ptr some more
} // free ptr hereIn a more realistic case, say some object was handed off so it shouldn't be cleaned up anymore, you can just add a should_cleanup flag and check it in the defer block. There's really no need for guard.
Their other example for guard, running defer in a loop, requires closures. This means it requires dynamic memory allocation and so the complexity goes through the roof.