:-)

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]

-----Ursprüngliche Nachricht-----
Von: Bingzhi via Std-Proposals <std-proposals@lists.isocpp.org>
Gesendet: Mo 10.08.2026 16:28
Betreff: Re: [std-proposals] Std-Proposals Digest, Vol 89, Issue 15
An: std-proposals@lists.isocpp.org;
CC: Bingzhi <bingzhi2025@163.com>;

You maybe right. But in modular context (C++20 Modules), I believe it's ok.
BTW, can you give an example to illustrate that defect ? I just can't think of a reasonable situation.

------------------------------------------------------------------------------------------------------------------------------------------------

Oh, I know, it's function (template) overload problem. But in that case, I think it's rather an ill-formed code than a defect. Just like normal usages of final, I really think that the core language lacks a way to ban overloads or specializations just like the way to ban derived classes or overrides.

 

 

 

 

>Date: Mon, 10 Aug 2026 12:33:05 +0200 >From: Bo Persson <bo@bo-persson.se> >To: std-proposals@lists.isocpp.org >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). >This would all be very sensitive to include order, if overloads are  >forbidden only after the 'final'. 

-- 
 Std-Proposals mailing list
 Std-Proposals@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals