:-) 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_at_[hidden]> Gesendet:Mo 10.08.2026 16:28 Betreff:Re: [std-proposals] Std-Proposals Digest, Vol 89, Issue 15 An:std-proposals_at_[hidden]; CC:Bingzhi <bingzhi2025_at_[hidden]>; 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_at_[hidden]> >To: 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). >This would all be very sensitive to include order, if overloads are >forbidden only after the 'final'. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals