Compilation strategy

[Walter Bright]

On 12/18/2012 9:42 AM, H. S. Teoh wrote:
> I was thinking more along the lines of things like fully automatic
> purity, safety, exception inference. For example, every function body
> eventually has to be processed by the compiler, so if a particular
> function is inferred to throw exception X, for example, then when its
> callers are compiled, this fact can be propagated to them. To do this
> for the whole program might be infeasible due to the sheer size of
> things, but if a module contains, for each function exposed by the API,
> a list of all thrown exceptions, then when the module is imported this
> information is available up-front and can be propagated further up the
> call chain. Same thing goes with purity and @safe.
>
> This may even allow us to make pure/@safe/nothrow fully automated so
> that you don't have to explicitly state them (except when you want the
> compiler to verify that what you wrote is actually pure, safe, etc.).

The trouble with this is the separate compilation model. If the attributes are 
not in the function signature, then the function implementation can change 
without recompiling the user of that function. Changing the inferred attributes 
then will subtly break your build.

Inferred attributes only work when the implementation source is guaranteed to be 
available, such as with template functions.

Having a binary format doesn't change this.