From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12180 invoked by alias); 24 Apr 2012 19:32:39 -0000 Received: (qmail 12166 invoked by uid 22791); 24 Apr 2012 19:32:37 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Apr 2012 19:32:25 +0000 From: "marc.glisse at normalesup dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53000] Conditional operator does not behave as standardized Date: Tue, 24 Apr 2012 19:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marc.glisse at normalesup dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg02173.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 Marc Glisse changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marc.glisse at normalesup | |dot org --- Comment #3 from Marc Glisse 2012-04-24 19:31:52 UTC --- (In reply to comment #2) > Confirmed. > > I suppose we could make the libstdc++ change now rather than waiting for the FE > fix, as it shouldn't change the current behaviour of the library. It doesn't seem completely obvious to me that this is the right library fix. What happens if instead of the standard declval you use the trivial version? template _Tp __declval2() noexcept; (except for the obvious problem with indestructible types, but then the decay version may give you an answer that isn't constructible from the input for references to a non-copyable type, so that's fair) Rereading the DR, it appears that some people actually want to decay independently from this rvalue issue, which is quite a strong change. And after all, people can use decay, but if decay is included in common_type, it can't be undone. Although now that I think as a library writer who has to specialize common_type for some of his types, I don't really want to specialize it for all cv-ref variants of my types, so I'd actually like the default common_type to decay not only the result, but also its arguments! And while we are at it, it could even try canonicalizing them, like operator auto(). Hmm, I guess you can forget this rant and go ahead (I am still posting it because there may be real arguments somewhere).