Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!uw-beaver!cornell!rochester!udel!burdvax!bpa!cbmvax!snark!eric
From: eric@snark.UUCP (Eric S. Raymond)
Newsgroups: comp.lang.c
Subject: Re: Another 'D' proposal (sigh)
Message-ID: <222ac04a:443c@snark.UUCP>
Date: 1 Mar 88 13:44:34 GMT
Organization: Thyrsus Enterprises, Malvern PA 19355
Lines: 25
Summary: 'True' is vague; use 'pure'
Discussion: <7282@oberon.USC.EDU>


In article <1893@phoenix.Princeton.EDU>, Raymond Juimong Chen writes:
>Propose that there be a way to declare "true functions", ie, functions
>whose return values depend on and are solely determined by the arguments
>passed to it.  They also have no side-effects.

Compiler folklore (and at least one major dialect of Pascal in which you can
declare them explicitly) calls such animals 'pure' functions.

>Implementation:
>I can think of two ways this could be implemented.  Let foo() be a
>"true function".
>
>register int foo(...)
>const int foo(...)

Not a bad idea. I'd prefer 'const' because it doesn't confuse the declaration
of the function's (lack of) side-effects with the declaration of the storage
class for its return type. Another kind of optimization this would permit
would be inlining.

Of course, the ANSI people will reject this on grounds of 'no prior art',
even though it's a better and better-tested idea than 'noalias'.
-- 
      Eric S. Raymond                  (the mad mastermind of TMN-Netnews)
      UUCP:  {{seismo,ihnp4,rutgers}!cbmvax,sdcrdcf!burdvax,vu-vlsi}!snark!eric
      Post:  22 South Warren Avenue, Malvern, PA 19355    Phone: (215)-296-5718