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 ;-)

  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: link
Be 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).