Date: Thu, 17 Feb 2022 23:06:32 +0100
I'm against piecemeal upgrading of C++ to C23 by near-copying
of normative text from the C23 standard library.
Since C++ does not show the funny function-like declaration from C
void assert(scalar expression)
but instead shows
#define assert(E) see below
where it's obvious that embedded commas might not do what you expect,
I think the "bug fix" argument falls on its face: C++ simply
has never accepted an arbitrary (phase 7) expression here, but only
one that is lexically preprocessor-friendly.
If you want to base C++26 on C23, then start writing a paper NOW,
as a first step showing an itemized list of differences C17 -> C23
so that L/EWG can form an opinion which features they want in C++.
Do you have any evidence of a paper falling between the cracks
since we've installed the github paper tracker?
Jens
On 17/02/2022 20.56, Peter Sommerlad (C++) via Liaison wrote:
> I am just wondering what legwork I still have to do for C++.
>
> With C, it seems my work is done, and I think with the reasoning given
> today at WG14, implementors could even make it a bug fix for previous
> language standards without much hassle (actually conforming to the
> pre-existing specification in the case of no NDEBUG).
>
> However, I am lost about what I have to do to get it into some future or
> even previous C++ standard (as a bug fix)?
>
> I have seen so many things falling between the cracks that I am honestly
> curious and careful.
>
> Regards
> Peter.
>
>
> Ville Voutilainen wrote on 17.02.22 20:51:
>> On Thu, 17 Feb 2022 at 21:40, Niall Douglas via Lib-Ext
>> <lib-ext_at_[hidden]> wrote:
>>>
>>>
>>> On 17/02/2022 19:12, Peter Sommerlad (C++) via Lib-Ext wrote:
>>>> OK, can we put the paper in the C++26 track in the hope someone will
>>>> write a paper to make C++26 based on C23?
>>>
>>> You could raise it as a defect against the 23 IS under the same basis as
>>> WG14's choice?
>>>
>>> I'm pretty sure implementers would prefer that both C and C++'s assert()
>>> are the same, anyway.
>>
>> Well, technically, mimic the way C specifies it - they specify it
>> as-if it's a function. Then the weasel-wording
>> about NDEBUG explains how it behaves in different modes, and the
>> practical implementation is as in your paper,
>> Peter.
>>
>
>
of normative text from the C23 standard library.
Since C++ does not show the funny function-like declaration from C
void assert(scalar expression)
but instead shows
#define assert(E) see below
where it's obvious that embedded commas might not do what you expect,
I think the "bug fix" argument falls on its face: C++ simply
has never accepted an arbitrary (phase 7) expression here, but only
one that is lexically preprocessor-friendly.
If you want to base C++26 on C23, then start writing a paper NOW,
as a first step showing an itemized list of differences C17 -> C23
so that L/EWG can form an opinion which features they want in C++.
Do you have any evidence of a paper falling between the cracks
since we've installed the github paper tracker?
Jens
On 17/02/2022 20.56, Peter Sommerlad (C++) via Liaison wrote:
> I am just wondering what legwork I still have to do for C++.
>
> With C, it seems my work is done, and I think with the reasoning given
> today at WG14, implementors could even make it a bug fix for previous
> language standards without much hassle (actually conforming to the
> pre-existing specification in the case of no NDEBUG).
>
> However, I am lost about what I have to do to get it into some future or
> even previous C++ standard (as a bug fix)?
>
> I have seen so many things falling between the cracks that I am honestly
> curious and careful.
>
> Regards
> Peter.
>
>
> Ville Voutilainen wrote on 17.02.22 20:51:
>> On Thu, 17 Feb 2022 at 21:40, Niall Douglas via Lib-Ext
>> <lib-ext_at_[hidden]> wrote:
>>>
>>>
>>> On 17/02/2022 19:12, Peter Sommerlad (C++) via Lib-Ext wrote:
>>>> OK, can we put the paper in the C++26 track in the hope someone will
>>>> write a paper to make C++26 based on C23?
>>>
>>> You could raise it as a defect against the 23 IS under the same basis as
>>> WG14's choice?
>>>
>>> I'm pretty sure implementers would prefer that both C and C++'s assert()
>>> are the same, anyway.
>>
>> Well, technically, mimic the way C specifies it - they specify it
>> as-if it's a function. Then the weasel-wording
>> about NDEBUG explains how it behaves in different modes, and the
>> practical implementation is as in your paper,
>> Peter.
>>
>
>
Received on 2022-02-17 22:06:36