@api: One attribute to rule them All

[Zach the Mystic via Digitalmars-d]

On Monday, 5 January 2015 at 21:15:00 UTC, Zach the Mystic wrote:
> https://github.com/D-Programming-Language/dmd/pull/1877

Deep into the discussion on the above pull, Walter responds to 
this comment of Kenji's:

"I think this kind of optimization should be hidden after the 
semantic phase - as like inlining and backend optimizations."

...with this:

"The trouble with doing this is that it is extremely dangerous in 
a language that supports separate compilation. It means that a 
function can be treated as pure, but its mangled signature says 
its impure. Then, the build system swaps in another version of 
that function, with the same signature, but is impure. Now the 
code that calls it is silently broken - the worst kind of runtime 
error.
This is why attribute inference is limited to those functions 
where the definitions are guaranteed to be available - templates, 
lambdas, nesteds and autos - then there can be no runtime 
mismatch."

What bothers me about this is that the compiler could *know* that 
a function is pure any time it has the function body available to 
it, regardless of what kind of function it is. The above quote 
suggests, however, that it's just completely impossible for the 
compiler to know if the function which will be called is the one 
that it has just compiled, or if it will be swapped in by a 
linker with another function with the same name from somewhere 
else. I honestly don't know enough about how linking works to 
know if this cancels my proposal. Wouldn't it cause an error if 
the linker found two of the exact same function?

My naive assumption about it is that when the compiler has the 
body, it can treat it as pure from within, even if it gets 
expressed by 'extern(noinfer)' as impure. That is, from within 
the singly compiled program, it can be treated as if it *is* 
pure, being one-hundred percent certain that the function it 
compiles will be the one that gets called at binary time, but for 
anyone reading the expressed interface, it can only be compiled 
as if it's *not* pure, since that's all the information the 
interface tells them.