[vitus]

I don't think we actually need `->void` -- shouldn't the compiler be able to infer the return type (or rather, absence thereof)? My experience is that the compiler only struggles when the return value needs to be implicitly converted to some other type.

Would it have looked any less cursed if it just read `defer { CoUninitialize(); };`?

Agreed that the simplest "fix" would be to just rename the macro to be all-caps.

[quietbritishjim]

> I don't think we actually need `->void`

Yes, agreed.

> Would it have looked any less cursed if it just read `defer { CoUninitialize(); };`?

It's subjective but personally I still hate it.

> Agreed that the simplest "fix" would be to just rename the macro to be all-caps.

Actually I think the bigger part of my suggestion is switching from an object-like macro to a function-like macro [1], which makes it all a bit less magical.

[1] https://stackoverflow.com/questions/36126687/function-like-m...

[vitus]

And, I personally hate macros that pretend to be functions but provide no visual indicator that they're not actually functions. For instance, `#define min(x, y) (x < y ? x : y)` evaluates its args multiple times. It's a little less bad when it only takes a single argument, but I am still irritated by things like htonl.

I think the "best" approach here would be to make it a function-like macro, and also change the name to all caps.

(Also, I tend to agree that `defer { ... };` is still cursed -- it requires the trailing semicolon, which further breaks the illusion of a keyword that takes a block scope.)