Date: Fri, 13 Mar 2020 12:00:41 +0100
Forgot to reply to all
---------- Forwarded message ---------
Od: Maciej Cencora <m.cencora_at_[hidden]>
Date: pt., 13 mar 2020 o 00:59
Subject: Re: [std-proposals] Fixing C-style arrays
To: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
As you already figured out, array == array comparison is already deprecated
in C++20.
I admit I didn't think of your third case (which I agree that should be
deprecated as well).
In this context char *argv[] is a completely different beast compared to
int a[2].
The construct 'char *argv[]' would not be affected buy the deprecation,
because the size of nested array is not provided, so it can rightfully
apply to array of any size.
pt., 13 mar 2020 o 00:48 Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
napisał(a):
> On Thu, Mar 12, 2020 at 5:40 PM Maciej Cencora via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> I propose to deprecate in C++23:
>> 1) mixed pointer and array comparisons:
>> int a[2]; int b[2];
>> a == &b[0];
>>
>
> Okay... but why "mixed"? Why not just deprecate *all* relational/equality
> operators where either side (or both) is an array?
>
> bool one(const char *p) { return *p == "hello"*; } // definitely a
> bug
> bool two(int x, int y) { int a[2] = {x,y}; int b[2] = {3,4}; return (*a
> == b*); } // definitely a bug
> const char *three(const char *p) { static const char arr[] = "hello";
> return (*p == arr*) ? nullptr : arr; } // not a bug, but perhaps
> expendable if its sacrifice buys us something good
>
> GCC, Clang, and MSVC all warn on `one`.
> Clang warns twice on `two`, even going so far as to claim that comparison
> between two arrays is already deprecated(!).
> Nobody warns on `three`.
>
>
>
>> 2) array decl in func parameters:
>> void foo(int a[2]);
>>
>
> Sadly, you can't do this. It's true that nobody should ever write what
> you have there <https://lkml.org/lkml/2015/9/3/428>; but there's simply
> too much code out there of the form
>
> int main(int argc, char *argv[])
>
> to ever permit a general deprecation of the notation.
> Vendors could certainly start warning on it, though.
>
> Does clang-tidy support a check for "misleading array syntax in parameter
> declaration"?
>
> –Arthur
>
---------- Forwarded message ---------
Od: Maciej Cencora <m.cencora_at_[hidden]>
Date: pt., 13 mar 2020 o 00:59
Subject: Re: [std-proposals] Fixing C-style arrays
To: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
As you already figured out, array == array comparison is already deprecated
in C++20.
I admit I didn't think of your third case (which I agree that should be
deprecated as well).
In this context char *argv[] is a completely different beast compared to
int a[2].
The construct 'char *argv[]' would not be affected buy the deprecation,
because the size of nested array is not provided, so it can rightfully
apply to array of any size.
pt., 13 mar 2020 o 00:48 Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
napisał(a):
> On Thu, Mar 12, 2020 at 5:40 PM Maciej Cencora via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> I propose to deprecate in C++23:
>> 1) mixed pointer and array comparisons:
>> int a[2]; int b[2];
>> a == &b[0];
>>
>
> Okay... but why "mixed"? Why not just deprecate *all* relational/equality
> operators where either side (or both) is an array?
>
> bool one(const char *p) { return *p == "hello"*; } // definitely a
> bug
> bool two(int x, int y) { int a[2] = {x,y}; int b[2] = {3,4}; return (*a
> == b*); } // definitely a bug
> const char *three(const char *p) { static const char arr[] = "hello";
> return (*p == arr*) ? nullptr : arr; } // not a bug, but perhaps
> expendable if its sacrifice buys us something good
>
> GCC, Clang, and MSVC all warn on `one`.
> Clang warns twice on `two`, even going so far as to claim that comparison
> between two arrays is already deprecated(!).
> Nobody warns on `three`.
>
>
>
>> 2) array decl in func parameters:
>> void foo(int a[2]);
>>
>
> Sadly, you can't do this. It's true that nobody should ever write what
> you have there <https://lkml.org/lkml/2015/9/3/428>; but there's simply
> too much code out there of the form
>
> int main(int argc, char *argv[])
>
> to ever permit a general deprecation of the notation.
> Vendors could certainly start warning on it, though.
>
> Does clang-tidy support a check for "misleading array syntax in parameter
> declaration"?
>
> –Arthur
>
Received on 2020-03-13 06:03:41