public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "h2+bugs at fsfe dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/103904] [defect fix] Please backport P2325R3 to 10 and 11 Date: Tue, 04 Jan 2022 17:13:13 +0000 [thread overview] Message-ID: <bug-103904-4-HkF8QqRxxP@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103904-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103904 --- Comment #6 from Hannes Hauswedell <h2+bugs at fsfe dot org> --- Yes, I understand that, and I know that it is your role to uphold these rules (which I believe make a lot of sense in general) and that you have other interests to consider beyond mine :) I would still like to sum up the points that I see in favour of deviating from that rule: * GCC10 is still young, the chances that codebases have come to rely on exactly this behaviour is lower now than it will be when e.g. the next Debian stable is released. Backporting will reduce breakage in the long run. * As you have pointed out, the feature has been hidden behind the non-standard c++20-flag. People had to explicitly opt-in to use this feature and were made aware that it is experimental. * The concept becomes more general than before, and all standard library types that previously met its requirements still meet the old requirements (standard library views are still default-initializable). So I expect *most* old code that uses views to just keep working. * I don't know if this counts as an argument, but I would argue that people whose code breaks because they rely on something not being a view that is now considered a view, are also the kind of people who will be able to fix this quickly ;-)
next prev parent reply other threads:[~2022-01-04 17:13 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-04 15:22 [Bug c++/103904] New: " h2+bugs at fsfe dot org 2022-01-04 15:45 ` [Bug libstdc++/103904] " redi at gcc dot gnu.org 2022-01-04 15:46 ` redi at gcc dot gnu.org 2022-01-04 15:51 ` redi at gcc dot gnu.org 2022-01-04 15:55 ` h2+bugs at fsfe dot org 2022-01-04 16:13 ` redi at gcc dot gnu.org 2022-01-04 17:13 ` h2+bugs at fsfe dot org [this message] 2022-01-05 8:42 ` rguenth at gcc dot gnu.org 2022-02-08 15:53 ` h2+bugs at fsfe dot org 2022-02-08 16:30 ` redi at gcc dot gnu.org 2022-02-08 16:54 ` redi at gcc dot gnu.org 2022-02-08 20:58 ` h2+bugs at fsfe dot org 2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org 2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org 2022-02-11 14:04 ` cvs-commit at gcc dot gnu.org 2022-02-11 20:40 ` cvs-commit at gcc dot gnu.org 2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org 2022-05-31 18:39 ` cvs-commit at gcc dot gnu.org 2022-05-31 18:49 ` ppalka at gcc dot gnu.org 2022-05-31 19:50 ` h2+bugs at fsfe dot 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-103904-4-HkF8QqRxxP@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).