Ah, indeed, but the language design respects the class/function designer all along. It's tricky when things come to the field of safety and code discipline, but for optimization, for compile-time performance, it's much more clearer.
`final template` (not including `final` overload) is just like the current `final` keyword itself. It's designed not just to ban something, but also to give an explicit early-optimization signal to the compiler. Come to think of it, why hasn't the language also introduce final public/private/protected to ban public/private/protected inheritance? Because access controls rarely give useful information for compiler to compile faster or generate faster code. (BTW, there's really some interview quiz just to scare people away: how to implement `final` without `final` keyword, how to ban public inheritance while allowing private/protected inheritance)
Same as `const` keyword itself, all checks could be moved into a static analyzer, but compiler still needs it to generate faster code or generate code faster.


>Message: 3
>Date: Wed, 12 Aug 2026 09:46:35 +0200
>From: Sebastian Wittmeier <wittmeier_at_projectalpha.org>
>To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
>Subject: Re: [std-proposals] Sebastian Wittmeier Re: Extending the
> usage of final: trying to > make compiler optimize more aggressively
> and trying to make the > language have a proper way to represent
> customization point objects > (CPO). [was: Std-Proposals Digest,
>Message-ID:
> <zarafa.6a7c24db.1e5d.26bcba825dbba916_at_lvps176-28-11-36.dedicated.hosteurope.>
>
>Content-Type: text/plain; charset="utf-8"
>
>The post was the half-serious, half-funny (I should have marked) observation that there are proposals
>
>to help with hacking: define automatic wrappers, extend a class with private functions which are not in the class definition, to override final functions, ...
>
>And then there are the proposals to limit access, to drop variables, to redact functions, ...
>
>Taken together it is a meta-fight about whether the author of a class has authority over it, or whether there are C++ features to override this authority, and any user of a class has final authority.
>
>My joke was that for the exact new feature stopping some access, one or two standards later new a new feature is suggested to override this denial of access.
>
>In some cases this gives nice flexibility, in others it totally contradicts the intent of the first feature and has to be forbidden in coding guidelines (or upcoming profiles) to keep any teeth, to stay in any way meaningful,
>
>e.g. from const 'feature' a const_cast 'feature' follows, but is a red flag in any code review, if there is no good explanation to use it. (for the architecture, but can be even UB in some cases).
>
>