To be honest, I'm not even a fan of having "sections" for member access
specifiers, and every language after C++ (at least to my knowledge) made it
so that you explicitly specify private/public for each function.

One negative effect is that it pressures people to put their code into
"public sections" and "private sections", and I don't find that to be the
most readable and helpful order whatsoever when it comes to understanding a
class by reading it from top to bottom. I would usually group all the
constructors together for example, irrespective whether they are public or
private.

I would also usually put the const-qualified getter overload right next to
the non-const one (like optional::value) instead of putting all the const
functions into a "const section". Other than maybe virtual, I don't think
any of your proposed keywords is suitable for forming "sections", and even
that one is debatable. That makes your suggested feature pretty much
useless to me, even if I wanted to use it, which I wouldn't.

Letting you create more such sections within a class just compounds the
issue. It's just a slightly more concise way (sometimes) to write something
we can already write. I would rather just live with the simple verbosity
that we have now instead of introducing another complicated style problem
that people disagree on.

On Wed, 15 Jul 2026 at 05:06, Walt Karas via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Allow const and/or static and/or noexcept and/or virtual and/or override
> between a member access specifier and the colon. This will affect members
> to which access is determined by the access specifier.
>
> If const appears, affected member variables will be const, and affected
> member references will be references to const. For non-static affected
> member function, the this pointer will be a pointer of a const object.
> There must be no affected member function for which the this pointer cannot
> be a pointer to const.
>
> If static appears, affected members will be static. There must be no
> affected member function that is not permitted to be static. If static
> appears, neither virtual nor override may appear after the same member
> access specifier.
>
> If noexcept appears, affected member functions will be noexcept.
>
> If virtual appears, non-static affected member functions will be virtual,
> except for constructors.
>
> If override appears, non-static affected member functions are virtual and
> must override virtual functions in base classes.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>