This reminded me: we are missing constexpr and maybe consteval.

I’m a little fuzzy on the details about the following. So, maybe someone else can chime in or correct me if necessary. IIRC there is something about the ordering/memory layout of member variables in one of the recent standards. Aren’t variables supposed to be clustered by public/private/protected? Or was this restriction lifted? How do we proceed with this when we have even more sections?

> On Jul 15, 2026, at 7:03 AM, SD SH via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> 
> Please consider these code:
>
> ```
> class X {
> public noexcept:
> void foo1() noexcept(false); // should it be ill-formed?
>
> void foo2() const;
> public const:
> void foo3() noexcept;
> // are `foo2` and `foo3` easy to read?
>
> public static const:
> int val1 = 0;
> // in the proposal, it equals to:
> // `public: static const int val1 = 0;`
> // but the code is incorrect, even if it seems no problems.
>
> public const virtual:
> void foo4() {
> /* do something doesn't need polymorphism */
> }
> // sometimes some well-formed but not best code will replace the best code while we don't know.
>
> int val2 = 0;
> public const:
> int val3 = 0;
> // there is no difference between the "sections" of `val2` and `val3`, but it is hard to say their "sections" are same.
> };
>
> void X::foo3() noexcept { } // forgetting to write down some of the specifiers will be a common problem.
> ```
>
> what are the reasons for prohibiting those who want to from using this proposal to reduce repetition?
> Personally, it doesn't bring much more convenience but brings more troubles in programming.
>
> If I can, I even want to write access specifiers for each member.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals