It is also possible to think of things the other way round.

These various "qualifiers" (I don't know if there is an appropriate term
that covers all these features) are today written in three different
places, yet they all exist to modify the member function declaration in
some form. "public:", "private:" and "protected:" are all written
earliest, and apply to all following members. "static" and "virtual"
are written before the main part of the function declaration, "const",
"noexcept" and "override" come after it.

With this proposal (or something similar), we could be more consistent :

 public noexcept override : foo(int x) -> int;

Rather than thinking that the proposal would mean people arranging their
declarations according to similarly-qualified sections, it could mean
that people would stop thinking in terms of private and public sections,
and rather think of these as a qualifier list for each declaration.

I don't know how realistic this is, and it is obviously too late to
change C++ to make it require explicit public/private for each member.
So I am not sure the proposal is a good idea overall (though I would, as
another poster said, think that "public noexcept:" would be useful).

(I expect member variables would still be in "sections", rather than
having their own set of qualifiers and specifiers for each declaration.)

David



On 15/07/2026 05:53, Jan Schultke via Std-Proposals wrote:
> 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] <mailto: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] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>