Thanks for the fast feedback, Sebastian and Jens.

I’ll give some more thought to the potential use cases in the standard library, as well as the interaction with reflection.

One aspect I would strongly consider, however, is exclusivity between the different modifier application styles. For example, a modifier should be applicable either at class scope, block scope, or individual member scope (as is currently the case), but mixing these approaches within the same type should not be allowed. In my opinion, permitting arbitrary mixing or opting in/out would make the model harder to reason about and would ultimately defeat part of its purpose.

Conceptually, I would rather see users select exactly one “mode” for a given class. For example (hypothetically):

struct S constexpr {
    int f();
    int g();
    // removing constexpr-ness for individual members
    // would not be possible in this mode
};

OR

struct S {
constexpr:
    int f();
    int g();

constexpr(false):
    int h();
};

OR the current/default approach:

struct S {
    constexpr int f();
    constexpr int g();
    int h();
};

The compiler could automatically detect which mode is being used (similar to how coroutines are recognized via co_* keywords), diagnose ambiguities, and emit compile-time errors when modes are mixed.

A similar approach could also be applied to noexcept or potentially other modifiers/specifiers.

The user would then choose the most appropriate mode depending on the requirements of the class. One side effect that I personally find attractive is that this could encourage cleaner class design. Roughly speaking, I would consider the approaches ordered from “strongest” to “weakest” guarantees as:

1 > 2 >= 3

For example, approach (1) naturally partitions types into equivalence classes with respect to a given specifier, which could make reasoning about properties such as constexpr behavior or exception safety significantly easier.

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: 22 May 2026 11:03
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] Floating idea: grouping common function qualifiers to reduce syntactic repetition


Perhaps another avenue to get this feature without double the changes is metaclasses (Reflection).



They would enable classes with automatic getters/setters (for those who want them), or serialization or ensuring regularity (rule-of-#) or new defaults (like constexpr).



Then a function qualifier could be made a default for all members of a class.



-----Ursprüngliche Nachricht-----
Von: Jens Maurer via Std-Proposals <std-proposals_at_[hidden]>
Gesendet: Fr 22.05.2026 10:30
Betreff: Re: [std-proposals] Floating idea: grouping common function qualifiers to reduce syntactic repetition
An: std-proposals_at_[hidden];
CC: Jens Maurer <jens.maurer_at_[hidden]>;


On 5/22/26 10:20, Daniel Petrovic via Std-Proposals wrote:
> *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

Not really. These are all keywords; this should be designed not to cause
another "most vexing parse" situation.

> * 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

I can see this to be useful for "constexpr" ("look, this entire class is constexpr-compatible").
For the other qualifiers, there is either a common code style recommendation not to
use them excessively (noexcept) or a meaningful variation within a class where a
scope-like grouping doesn't seem to be desirable (const, virtual).

Is there an opt-out planned? ("all member functions in this class are constexpr,
except this one")

You could gather some indication of usefulness by checking how existing code
would benefit. Start with the standard library.
I think you'll find plenty of examples for "constexpr an entire class", but zero
examples for the other keywords.

Jens

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals