I would absolutely use "public noexcept:" just to make it impossible to use
exceptions in an unsafe template. Overall it looks useful, "public const:"
is the only one I'm skeptical about. Or we could just declare the language
part feature complete.



On Tue, Jul 14, 2026 at 9:07 PM Walt Karas via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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_at_[hidden]> 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]> 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
> >
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>