On Tue, Dec 18, 2012 at 08:12:51AM -0800, Walter Bright wrote: > On 12/18/2012 7:51 AM, H. S. Teoh wrote: > >An idea occurred to me while reading this. What if, when compiling a > >module, say, the compiler not only emits object code, but also > >information like which functions are implied to be strongly pure, > >weakly pure, @safe, etc., as well as some kind of symbol dependency > >information. Basically, any derived information that isn't > >immediately obvious from the code is saved. > > > >Then when importing the module, the compiler doesn't have to > >re-derive all of this information, but it is immediately available. > > > >One can also include information like whether a function actually > >throws an exception (regardless of whether it's marked nothrow), > >which exception(s) it throws, etc.. This may open up the possibility > >of doing some things with the language that are currently infeasible, > >regardless of the obfuscation issue. > > This is a binary import. It offers negligible advantages over .di > files.
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.). T -- Тише едешь, дальше будешь.