From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3713 invoked by alias); 26 Aug 2012 23:13:43 -0000 Received: (qmail 3704 invoked by uid 22791); 26 Aug 2012 23:13:42 -0000 X-SWARE-Spam-Status: No, hits=-3.6 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; Sun, 26 Aug 2012 23:13:30 +0000 From: "jewillco at osl dot iu.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/54379] New: Suggestion for type attribute similar to warn_unused_result Date: Sun, 26 Aug 2012 23:13:00 -0000 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: enhancement X-Bugzilla-Who: jewillco at osl dot iu.edu 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 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-08/txt/msg01784.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54379 Bug #: 54379 Summary: Suggestion for type attribute similar to warn_unused_result Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned@gcc.gnu.org ReportedBy: jewillco@osl.iu.edu I think it would be useful to extend GCC with an attribute similar to `warn_unused_result` but applying to a user-defined type rather than just a single function. The effect would be that all expressions (variable references, function calls, etc.) that return some object of that type would warn if their results were unused. The intended use case is for C++ patterns such as expression templates in which purely-functional code builds up an expression tree which does not make sense to discard; in some cases, operator= would just add to the expression tree as well, leading to a source of bugs. This would probably require the kind of cast-to-void override mechanism that PR 25509 is about, since these annotations would strictly be recommendations.