On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
On 07-05-2012 14:50, Steven Schveighoffer wrote:
On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
<xtzgzorex@gmail.com> wrote:
On 07-05-2012 13:21, Steven Schveighoffer wrote:
On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
<xtzgzorex@gmail.com> wrote:
Purity inference won't happen either way. Purity is part of your API
and also meant to help you reason about your code. If the compiler
just infers purity in a function and you later change the
implementation so it's no longer pure, you break your users' code.
Also, purity would no longer help you reason about your code if it's
not explicit.
It can be pure for the purposes of optimization without affecting code
whatsoever. Inferred purity can be marked separately from explicit
purity, and explicitly pure functions would not be allowed to call
implicitly pure functions.
-Steve
But that kind of inferred purity is something a compiler back end
cares about, not something the language should have to care about at
all. In practice, most compilers *do* analyze all functions for
possible side-effects and use that information where applicable.
It affects how callers code will be generated.
If I have a function
int foo(int x);
and I have another function which calls foo like:
int y = foo(x) + foo(x);
Then the optimization is applied to whatever function this exists in. If
the source isn't available for foo, the compiler cannot make this
optimization.
I have no idea if this is a back-end or front-end issue. I'm not a
compiler writer. But I do understand that the compiler needs extra
information in the signature to determine if it can make this optimization.
OK, point taken; didn't consider that. But in the first place, for inference of purity to work, the source would have to be available. Then, that inferred property has to be propagated somehow so that the compiler can make use of it when linking to the code as a library...
That's exactly what storing the interface in the object file does. You don't need the source because the object file contains the compiler's interpretation of the source, and any inferred properties it has discovered.
Putting inferred purity into an object file sounds like a bad idea. It's not hard to imagine this scenario:
-function foo in libSomething is inferred as pure (but not declared pure by the author)
-exeSomethingElse is compiled to use libSomething, and the compiler takes advantage of purity optimizations when calling foo
-libSomething is recompiled and foo is no longer pure, and exeSomethingElse silently breaks
Purity inference is fine for templates (because recompiling the library won't change the generated template code in an executable that depends on it), but in all other cases, the API needs to be exactly what the author declared it to be, or strange things will happen.