It seems to me that the proper way to frame the argument is: what are the reasons for prohibiting those who want to from using this proposal to reduce repetition? There is currently nothing that prevents an access specifier for each class member. Is it correct to hold that the "sections for members" water is warm enough to wade in ankle deep, but too cold to go deeper?






On Tuesday, July 14, 2026 at 11:53:25 PM EDT, Jan Schultke <janschultke@googlemail.com> 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@lists.isocpp.org> 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@lists.isocpp.org
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals