C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Floating idea: grouping common function qualifiers to reduce syntactic repetition

From: Sebastian Wittmeier <wittmeier_at_[hidden]>
Date: Fri, 22 May 2026 10:24:48 +0200
Sorry, just saw you did it that way. Answered on my smartphone with too much scrolling. Sorry for the list.   -----Ursprüngliche Nachricht----- Von:Sebastian Wittmeier <wittmeier_at_[hidden]> Gesendet:Fr 22.05.2026 10:23 Betreff:AW: [std-proposals] Floating idea: grouping common function qualifiers to reduce syntactic repetition An:std-proposals_at_[hidden]; You give the defaults at class level. How to remove it for single members?   Perhaps better (if going with your idea) would be to do it more similarly to private: which can be changed to public: or protected: within a class.   public const:   private constexpr:   public virtual:   -----Ursprüngliche Nachricht----- Von:Daniel Petrovic via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 22.05.2026 10:20 Betreff:[std-proposals] Floating idea: grouping common function qualifiers to reduce syntactic repetition An:std-proposals_at_[hidden]; CC:Daniel Petrovic <daniel-dev_at_[hidden]>; Hello all, This is a floating idea intended to explore possible directions by extending the core language by (optionaly) reducing syntactic repetition in C++, not a concrete proposal. Motivation As C++ continues to evolve, functions increasingly accumulate multiple qualifiers (const, noexcept, constexpr, virtual, etc.). While each serves a clear purpose, the repeated spelling of identical qualifier sets across many member functions can make interfaces verbose and harder to read, especially for newcomers. For example: class A { public:  const int ​f() const noexcept;  double g() const noexcept;  void h() const noexcept; }; The repetition here is mechanical rather than expressive. Idea: qualifier grouping blocks One possible direction would be to allow grouping of common qualifiers in a declaration block, with enclosed declarations implicitly inheriting them . Illustrative syntax (purely hypothetical): class A { public const noexcept: // note: const is for the object const'nes   const int f();  double g();  void h(); }; This would be equivalent to today’s spelling, but visually emphasizes what varies (the function names and signatures) rather than what does not. Class-level qualifiers A similar idea could apply at class scope for qualifiers like constexpr, when meaningful: struct S constexpr {  S();  ~S();  int f();  int g(); }; Which would be equivalent to: struct S {  constexpr S();  constexpr ~S();  constexpr int f();  constexpr int g(); }; This could be seen as analogous to how access specifiers already work at block scope. Potential benefits * Reduces visual noise caused by repetitive qualifiers * Improves readability of interfaces with many similarly-qualified members * Makes class declarations less intimidating to newer developers * Encourages consistency (qualifiers are declared once, not copied) Open questions / concerns * Which qualifiers would be eligible? (const, noexcept, constexpr, virtual, others?) * Interaction with overrides, ref-qualifiers, attributes, and trailing requires-clauses * Parsing complexity * Whether this meaningfully improves clarity compared to existing verbosity * Risk of hiding important semantics “far away” from the function declaration Prior art / comparison This idea is conceptually similar to: * Access specifier blocks (public:, private: or Qt signals:, slots:) * Attribute grouping in some other languages * Namespace-level defaults or pragmas However, C++ traditionally favors explicitness at the declaration site, so this would represent a shift in style. Intent The goal is not to reduce expressiveness or weaken type safety, but to explore whether the language could offer a more approachable and readable way to express common patterns that already exist in practice. I’m interested in feedback on whether this direction is worth exploring further, what pitfalls I may be missing, or whether similar ideas have already been discussed or rejected. Thanks for your time.   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2026-05-22 08:27:30