Oh, yes. For pure overload sets without any function templates, that's true. So that part is indeed useless. But what about that `final template` part? I don't have a strict verification or test result, but I believe that `final template` can pass necessary optimization information to the compiler, just as `noexcept` or `const` keyword do. I truly need templates to be memoized like concepts; the compiler doesn't need to wait until the final instantiation requested by user code and then level by level instantiates each template. There are huge examples that need this feature: std::declval, std::move, std::forward, many query traits in <type_traits>, std::enable_if, std::conditional, std::conjunction/disjunction. Currently there're some attributes to achieve the check that no further more specialization appears, but there's no guarantee that compiler will use this attribute to optimize huge template instantiation process.



At 2026-08-12 15:49:55, "Simon Schröder" <dr.simon.schroeder_at_[hidden]> wrote:

There is no optimization potential for overload resolution. At compile time the compiler looks at all visible overloads, picks one of these and puts the exact call into the generated code. It's basically the same with templates. At compile time the set of overloads or templates is "final". And compilers don't have any smart caches between compilation runs. It would also not help as the 'final' keyword can be removed any time by the programmer.


So, the 'final' keyword would only restrict the programmer, but does not help the compiler.


On Wed, Aug 12, 2026 at 7:46 AM Bingzhi via Std-Proposals <std-proposals_at_[hidden]> wrote:

`overide ban`? Do you mean transitivity? Or, is there a reason to ban the ban of [overloads, specializations, derived classes, overrides] afterwards?
It's wholly for optimizing compilation performance, not for safety or code constraints (that could be achieved via third-party static analyzers).
If compiler knows early that a template only has those specializations/overloads and no more, it can optimize more aggressively, which might make a `final template <std::meta::info type> consteval bool compute()` even faster than its un-`finalized` variable template counterpart, with even more flexibility; you can just use if-constexpr and iterate over a result freely instead of using a bunch of concepts and requires just for reducing compilation time (in the cost of more brain cells or your colleagues' brain cells).


>Message: 4
>Date: Mon, 10 Aug 2026 18:19:00 +0200
>From: Sebastian Wittmeier <wittmeier_at_[hidden]>
>To: std-proposals_at_[hidden].org <std-proposals_at_[hidden]>
>Subject: Re: [std-proposals] 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, Vol 89, Issue 15]
>Message-ID:
> <zarafa.6a79f9f4.6e85.6f81ddd17532c953_at_lvps176-28-11-36.dedicated.hosteurope.>
>
>Content-Type: text/plain; charset="utf-8"
>
>:-)
>
>C++29:
>
>Proposal for feature to ban [overloads, specializations, derived classes, overrides]
>
>?
>C++3x:
>
>Proposal for feature to override ban of [overloads, specializations, derived classes, overrides]
>
>for [customization, debugging, hacking, reviving old code, testing]
>

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals