From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21182 invoked by alias); 29 Apr 2002 16:23:44 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21171 invoked from network); 29 Apr 2002 16:23:43 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 29 Apr 2002 16:23:43 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id C2341F29F3; Mon, 29 Apr 2002 12:23:19 -0400 (EDT) To: dewar@gnat.com, sabre@nondot.org Subject: Re: pure and const functions Cc: gcc@gcc.gnu.org Message-Id: <20020429162319.C2341F29F3@nile.gnat.com> Date: Mon, 29 Apr 2002 09:29:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2002-04/txt/msg01557.txt.bz2 > I don't really agree with this. If the compiler can determine that it's > pure, the programmer shouldn't have to provide the annotation. Instead > (at least for the C/C++ frontends), I propose that we trust the programmer > to not do something dumb (scary I know...). These languages are built > around the notion that the programmer knows what they are doing, I don't > see how it would be any different here... In order for the programmer to "know what they are doing", you have to do one of two things: 1. Define what pure means semantically or 2. Define what the functional effect of declarting something pure is I actually think you *do* agree with me. What I said was that it was in practice impractical for the compiler to check that you are doing the right thing when you declare a function pure (though obvious problems might be detectable and cause appropriate warnings). As an example of a fuction that is unlikely to obey any set of semantic rules but in practice can be treated as pure, consider a sqrt function which is instrumented to count the number of times it is called. This is obviously not pure in the semantic sense, but operationally it may make perfect sense to treat it as pure.