public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "arthur.j.odwyer at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/114479] [14 Regression] std::is_array_v<int[0]> changed from false to true in GCC 14 Date: Mon, 01 Apr 2024 15:25:04 +0000 [thread overview] Message-ID: <bug-114479-4-NLrbq48GDP@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114479-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479 Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arthur.j.odwyer at gmail dot com --- Comment #5 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- IIUC, the logic here goes as follows: (1) Everyone's compiler extension currently makes this assertion fail, not succeed: #include <type_traits> template<class T> struct is_array : std::false_type {}; template<class T> struct is_array<T[]> : std::true_type {}; template<class T, std::size_t N> struct is_array<T[N]> : std::true_type {}; static_assert(is_array<int[0]>::value, "this assert fails"); (2) Everyone's library is expected to implement `std::is_array` as the moral equivalent of the partial specializations in (1). No reasonable library would ever do anything else. (3) Therefore, everyone's library will claim that int[0] is not an array type: static_assert(std::is_array<int[0]>::value, "this assert fails"); (4) The __is_array builtin is provided specifically to speed up std::is_array (and for no other reason). Therefore, it should give the same answer as (3). Therefore, __is_array(int[0]) should also report false: static_assert(__is_array(int[0]), "this assert fails"); This logic doesn't depend on any abstract reasoning about whether int[0] is really "an array type" (I think it certainly *is* an array type, FWIW); it simply depends on observing the extension's behavior in (1) -- and then *not* claiming that that's a bug we need to fix. If the extension's behavior is "correct" (i.e. we're not going to change it), then the behavior of __is_array(T[0]) falls naturally out of that. Personally, if I were designing the extension today, I would certainly make T[0] match the partial specialization for T[N] (with N=0). This seems like it would match users' expectations, and it doesn't seem to break any code that wasn't already trying to use the extension, except for pathological party tricks like being able to obfuscate the condition (N >= 1) as (std::is_array_v<int[N]>). However, *if* the extension's behavior (1) is set in stone, *then* conclusion (4) follows inexorably. And since both (1) and (4) are core-language compiler issues, libstdc++ isn't involved here: it's simply a bug for GCC to provide partial-specialization-matching behavior as in (1) without also providing __is_array behavior as in (4). HOWEVER, here's a big question which I believe Aaron Ballman also raised on llvm-project#54705: If it's not an array type, then where do we get off calling it a compound type ( https://eel.is/c++draft/basic#compound-1 ), a literal type ( https://eel.is/c++draft/basic#types.general-10 ), an aggregate ( https://eel.is/c++draft/dcl.init.aggr#1 ), etc? It certainly would be *simpler* -- if a big upheaval -- for GCC to provide neither (1) nor (4), i.e. change the specialization-matching behavior to match __is_array rather than the other way around. Then all the traits would give consistent answers: int[0] would be a compound type, a literal type, and an aggregate *because* it was an array type.
next prev parent reply other threads:[~2024-04-01 15:25 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-26 11:16 [Bug c++/114479] New: " nikolasklauser at berlin dot de 2024-03-26 11:42 ` [Bug c++/114479] [14 Regression] " pinskia at gcc dot gnu.org 2024-03-26 11:42 ` redi at gcc dot gnu.org 2024-03-27 7:57 ` rguenth at gcc dot gnu.org 2024-03-29 15:56 ` mpolacek at gcc dot gnu.org 2024-03-31 10:05 ` redi at gcc dot gnu.org 2024-04-01 14:28 ` mpolacek at gcc dot gnu.org 2024-04-01 15:25 ` arthur.j.odwyer at gmail dot com [this message] 2024-04-02 18:34 ` cvs-commit at gcc dot gnu.org 2024-04-02 18:35 ` mpolacek at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114479-4-NLrbq48GDP@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).