Date: Wed, 12 Aug 2026 17:43:55 +0800 (CST)
It's probably about cache hits/misses, hashes, and redundant checks. I don't know and can't prove how it works exactly.
Of course the compiler can't predict instantiations, but the compiler optimize away some unnecessary checks and be less lazier with additional user-provided information or more detailed language specification.
The key idea is to imitate the advantages of C++20 concepts (it's proved that concept and requires expressions are terribly faster than its variable templates counterparts), therefore trying to boost compilation of function templates, class templates, variable templates.
At 2026-08-12 17:26:58, "Simon Schröder" <dr.simon.schroeder_at_[hidden]> wrote:
The compiler kind of does need to wait for the instantiation to be requested. Especially in the case of std::move, etc. you don't know for which types this template needs to be instantiated inside the current translation unit. So, only at the place where the instantiation is requested do you know that it is required. Also, time-wise it doesn't matter if you instantiate a template at the beginning, in the middle or at the end. It takes exactly the same time.
At least with any change the compiler needs to work "as if" the template was instantiated when it was requested.
In this standardization process if you make a claim that compilation can be faster if we have this keyword (and that is the only reason for the keyword), we need proof of that. This means that you would have to provide a demo implementation (maybe based on GCC or clang) that shows this can save compilation times. Otherwise it is highly unlikely that this proposal is accepted based on this reasoning. But maybe I'm overlooking something and it is obvious to compiler implementers that this indeed improves compilation times.
On Wed, Aug 12, 2026 at 11:10 AM Bingzhi <bingzhi2025_at_[hidden]> wrote:
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_projectalpha.org>
>To: std-proposals_at_[hidden] <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_[hidden]ps176-28-11-36.dedicated.hosteurope.de>
>
>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]
>
Of course the compiler can't predict instantiations, but the compiler optimize away some unnecessary checks and be less lazier with additional user-provided information or more detailed language specification.
The key idea is to imitate the advantages of C++20 concepts (it's proved that concept and requires expressions are terribly faster than its variable templates counterparts), therefore trying to boost compilation of function templates, class templates, variable templates.
At 2026-08-12 17:26:58, "Simon Schröder" <dr.simon.schroeder_at_[hidden]> wrote:
The compiler kind of does need to wait for the instantiation to be requested. Especially in the case of std::move, etc. you don't know for which types this template needs to be instantiated inside the current translation unit. So, only at the place where the instantiation is requested do you know that it is required. Also, time-wise it doesn't matter if you instantiate a template at the beginning, in the middle or at the end. It takes exactly the same time.
At least with any change the compiler needs to work "as if" the template was instantiated when it was requested.
In this standardization process if you make a claim that compilation can be faster if we have this keyword (and that is the only reason for the keyword), we need proof of that. This means that you would have to provide a demo implementation (maybe based on GCC or clang) that shows this can save compilation times. Otherwise it is highly unlikely that this proposal is accepted based on this reasoning. But maybe I'm overlooking something and it is obvious to compiler implementers that this indeed improves compilation times.
On Wed, Aug 12, 2026 at 11:10 AM Bingzhi <bingzhi2025_at_[hidden]> wrote:
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_projectalpha.org>
>To: std-proposals_at_[hidden] <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_[hidden]ps176-28-11-36.dedicated.hosteurope.de>
>
>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
Received on 2026-08-12 09:44:05