Wrong by Default
It depends on what you are working on, and then even &quot;not wrong by default&quot; might be... wrong.<p>For low level code, destructors&#x2F;RAII are much harder to notice than a very explicit defer. Even the &quot;kernel C&quot; style &quot;goto done;&quot; to a unified exit point (sometimes multiple labels that fall into each other to clean up according to how far you got) wins out by explicitly telling you what will happen.<p>If you are working on projects where you often spend much more time reading code than subsequently writing code, and if the thing you are working on is not a high level application where the meat is in some business logic, then anything that reduces readability in the sense of &quot;I can see everything that is going on&quot; is very bad.<p>In low level code, the potential for icky problems is also much higher: You don&#x27;t want to find out that some stray destructor did something that should not have happened in e.g. an interrupt context, or while the current thread&#x27;s memory management is in an intermediate state. That is <i>not</i> correct by default, it is &quot;wrong and you didn&#x27;t even tell me&quot;.<p>In high level application software development, e.g. CRUD SaaS or a smartphone app, the opposite may be the case, and decluttering might well win out.