Send Std-Proposals mailing list submissions to
std-proposals@lists.isocpp.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
or, via email, send a message with subject or body 'help' to
std-proposals-request@lists.isocpp.org
You can reach the person managing the list at
std-proposals-owner@lists.isocpp.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Proposals digest..."
Today's Topics:
1. Re: Proposal: ranges::reserve (Giuseppe D'Angelo)
2. Re: Proposal: ranges::reserve (Yexuan Xiao)
3. Re: Allow const / static / noexcept / virtual / override
after member access specifier (Walt Karas)
----------------------------------------------------------------------
Message: 1
Date: Thu, 16 Jul 2026 14:05:22 +0200
From: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
To: std-proposals@lists.isocpp.org
Subject: Re: [std-proposals] Proposal: ranges::reserve
Message-ID: <003c1268-a2f7-4523-be30-df507d48286f@kdab.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 16/07/2026 10:24, Yexuan Xiao via Std-Proposals wrote:
> I have realized that the second version I proposed is incorrect and the
> first version is correct, except for its name and the parameter.
Just to better understand, are you proposing to expose/standardize the
functionality currently "hidden" into ranges::to?
Specifically the reserveable-container machinery in
https://eel.is/c++draft/range.utility.conv#to-2.1.4
https://eel.is/c++draft/range.utility.conv#general-3
Thanks,
--
Giuseppe D'Angelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4850 bytes
Desc: S/MIME Cryptographic Signature
URL: <
https://lists.isocpp.org/std-proposals/attachments/20260716/80b2e0b5/attachment.bin>
------------------------------
Message: 2
Date: Thu, 16 Jul 2026 12:35:09 +0000
From: Yexuan Xiao <bizwen@nykz.org>
To: "std-proposals@lists.isocpp.org" <std-proposals@lists.isocpp.org>
Subject: Re: [std-proposals] Proposal: ranges::reserve
Message-ID:
<SY6PR01MB77114F75187887B982E6167FD1C72@SY6PR01MB7711.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes, that's one way to understand it. I had previously overlooked and missed this feature of ranges::to. Thank you for providing this important information.
________________________________
From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Thursday, July 16, 2026 20:05
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Subject: Re: [std-proposals] Proposal: ranges::reserve
On 16/07/2026 10:24, Yexuan Xiao via Std-Proposals wrote:
> I have realized that the second version I proposed is incorrect and the
> first version is correct, except for its name and the parameter.
Just to better understand, are you proposing to expose/standardize the
functionality currently "hidden" into ranges::to?
Specifically the reserveable-container machinery in
https://eel.is/c++draft/range.utility.conv#to-2.1.4
https://eel.is/c++draft/range.utility.conv#general-3
Thanks,
--
Giuseppe D'Angelo
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 3
Date: Thu, 16 Jul 2026 18:27:13 +0000 (UTC)
From: Walt Karas <wkaras@yahoo.com>
To: "std-proposals@lists.isocpp.org" <std-proposals@lists.isocpp.org>
Subject: Re: [std-proposals] Allow const / static / noexcept / virtual
/ override after member access specifier
Message-ID: <651970870.1933051.1784226433566@mail.yahoo.com>
Content-Type: text/plain; charset=UTF-8
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@lists.isocpp.org> 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@lists.isocpp.org> 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
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
------------------------------
Subject: Digest Footer
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
------------------------------
End of Std-Proposals Digest, Vol 88, Issue 27
*********************************************