My thinking was that virtual following the access specifier would be moot for member variables. Come to think of it, friend would also be a candidate for appearing after the access specifier. friend would also be moot for member variables, using/typedef and classes.

I think I suggested the usefulness of virtual const member variables (with the value stored in the vtable) many years ago. But support was underwhelming.






On Wednesday, July 15, 2026 at 12:48:27 AM EDT, Simon Schröder via Std-Proposals <std-proposals_at_[hidden]> wrote:






I tend to agree with you. For me, also just virtual would be useful (and maybe static). Maybe we can extend this: These keywords after the access specifier would just change the defaults for a section. This would actually work well with noexcept, because we can mark individual functions noexcept(false). However, currently there are no proper keywords to define the opposite of const, static, or virtual (maybe there is mutable to oppose const).

Though most of these keywords work properly in all cases, it raises one question: What are virtual member variables?

> On Jul 15, 2026, at 5:53 AM, Jan Schultke via Std-Proposals <std-proposals_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

-- 
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals