<div class="gmail_quote">On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com" target="_blank">schveiguy@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley <<a href="mailto:wiley.andrew.j@gmail.com" target="_blank">wiley.andrew.j@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <<a href="mailto:schveiguy@yahoo.com" target="_blank">schveiguy@yahoo.com</a>>wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <<br>
<br></div><div class="im">
That's exactly what storing the interface in the object file does.  You<br>
don't need the source because the object file contains the compiler's<br>
interpretation of the source, and any inferred properties it has discovered.<br>
<br>
</div></blockquote>
<br><div class="im">
Putting inferred purity into an object file sounds like a bad idea. It's<br>
not hard to imagine this scenario:<br>
-function foo in libSomething is inferred as pure (but not declared pure by<br>
the author)<br>
-exeSomethingElse is compiled to use libSomething, and the compiler takes<br>
advantage of purity optimizations when calling foo<br>
-libSomething is recompiled and foo is no longer pure, and exeSomethingElse<br>
silently breaks<br>
</div></blockquote>
<br>
no, it just doesn't link.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Purity inference is fine for templates (because recompiling the library<br>
won't change the generated template code in an executable that depends on<br>
it), but in all other cases, the API needs to be exactly what the author<br>
declared it to be, or strange things will happen.<br>
</blockquote>
<br></div>
I agree that's the case with the current object/linker model.  Something that puts inferred properties into the object file needs a new model, one which does not blindly link code that wasn't compiled from the same sources.<br>

</blockquote><div><br></div><div>Then all you've done is to make attributes the author can't control part of the API, which will force library users to recompile their code more often for non-obvious reasons. Avoiding that is one of the points of shared libraries.</div>

<div><br></div><div>I think we're actually talking about different contexts. I'm speaking in the context of shared libraries, where I think the API needs to be exactly what the author requests and nothing more. With object files, static libraries, and static linking, I agree that this sort of thing could work and wouldn't cause the same problems because it's impossible to swap the library code without recompiling/relinking the entire program.</div>

</div><br>