From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15772 invoked by alias); 16 May 2011 21:36:33 -0000 Received: (qmail 15735 invoked by uid 22791); 16 May 2011 21:36:32 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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; Mon, 16 May 2011 21:36:17 +0000 From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/49015] New: [C++0x] Non-defining constexpr function declarations require complete argument/return types X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Mon, 16 May 2011 21:40:00 -0000 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: 2011-05/txt/msg01286.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49015 Summary: [C++0x] Non-defining constexpr function declarations require complete argument/return types Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: daniel.kruegler@googlemail.com CC: jason@redhat.com After successful resolution of bug 48948 gcc 4.7.0 20110514 (experimental) in C++0x mode now rejects the following code at the lines marked with #L-4 until #L-13: //--- class A; class B; constexpr B f(A); // #L-4 class B { friend constexpr B g(A); // #L-7 }; class A {}; constexpr B f(A) { return B(); } // #L-12 constexpr B g(A) { return B(); } // #L-13 //--- "4|error: invalid type for parameter 1 of constexpr function 'constexpr B f(A)'| 4|error: invalid return type 'B' of constexpr function 'constexpr B f(A)'| 7|error: invalid type for parameter 1 of constexpr function 'constexpr B g(A)'| 7|error: invalid type for parameter 1 of constexpr function 'constexpr B g(A)'| |In function 'constexpr B f(A)':| 12|error: redeclaration 'constexpr B f(A)' differs in 'constexpr'| 4|error: from previous declaration 'B f(A)'| |In function 'constexpr B g(A)':| 13|error: redeclaration 'constexpr B g(A)' differs in 'constexpr'| 7|error: from previous declaration 'B g(A)'| ||=== Build finished: 8 errors, 0 warnings ===| The parts following line 8 have mainly be added to demonstrate the general usefulness of the non-defining declarations and the error described by #L-12 and #L-13 is possibly overlaid by bug 48945 as well, so the main aspect of this issue are the #L-4 and #L-7 rejections if interaction with bug 48945 is the cause of #L-12 and #L-13. I don't think that the literal-type requirements as of 3.9 p. 10 impose the requirements of complete types for the non-defining declarations of these constexpr functions, IMO the requirement for the complete type is only required for the final definition of f and g, which also seems to be intended as described by the example of 7.1.5 p. 1. In principle these examples are also not much different from constexpr function templates, which must delay the evaluation until the concrete instantiation and usage (The last aspect becomes clear by the 7.1.5 p. 1 example and demonstrates that this is a general character of constexpr functions irrespective of templates).