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_[hidden]>
>> >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_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
>>
>