On 15 Jul 2026 06: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.

And I have always been annoyed by having to repeatedly qualify
public/private for each member in other languages. I think, C++ did it
right.

That said, access qualifiers are sufficiently different from the
features proposed by the OP, which are typically more varying across
members. It is typical to have a public interface of the class, which
naturally goes into the public section, and the implementation detail
which goes into the private section. Splitting into sections by
constness or virtuality is much less natural as this would result in
grouping not quite related things or splitting related ones (e.g.
getters and setters for a property would be in separate const and
non-const sections).

Another thing to consider is how the proposal would affect with member
definitions that are outside the class scope. Presumably, you would
still have to qualify const and noexcept for static data member
definitions and out-of-class member function definitions. Which means
there would be a discrepancy between how the member is specified in the
class vs. how it is defined out-of-class.

Yes, there is already such discrepancy wrt. static and virtual, which
is, IMO, unfortunate. But at least those two qualifiers don't affect the
type.

In general, I'm not in favor of this proposal as I think it would lead
to a more confusing code.